Hi,
Ok, I have spent the day looking at axis code, tyring to assest how much
work it would need to make my applets/axis work without the
NullSecurityManager. What I found was not pretty, because turns out that
getting rid of the logging code it's the easy part, the hard part is dealing
with the commons-discovery package that, not only uses the commong-logging
package extensively, but it in itself is the basis of the
EngineConfigurationFactoryFinder. The problem as I see it (a problem if you
are using an applet of course) is that the discovery creates a class loader
for each property or class it loads.
Now, I don't think I know the design that well to say that there is no easy
fix, but I see several options about how to deal with this:
1) Design an alternative AxisEngineApplet (instead of AxisEngine) to be used
by the Service class, which will not make use of the commons-discovery
package.
2) An alternative EngineConfigurationFactoryFinder? ... I don't know if this
could help, seems like you gain nothing as long as you use the
commons-discovery package.
3) Hack the discovery-commons package ... this is ugly, sounds more like
redesign than a hack. I don't think this is a good option, right?
4) Probably there is already a version that does something like this?
5) Get rid of applets and find another way to use AXIS-SOAP, Java and the
browser ... JavaScript? what other alternatives do I have?
Please let me know if any of this makes any sense. I would appreciate
comments one way or another.
Thanks in advance,
--Luis R.
From: "Luis Rivera" <[EMAIL PROTECTED]>
Reply-To: [email protected]
To: [email protected]
Subject: Re: Axis and Applet coexistence?
Date: Thu, 14 Jul 2005 15:30:26 -0700
Hi,
Well, now I found out that I had a bad certificate and a bad configuration
or instalation of the Job Console. After generating a new certificate and
reinstalling my browser I found out that signing the applet and using the
All Permited Seucrity Manager allows it to work "without the custom
security policy file". You still need to security manager, which is not
exactly good and I am still hoping that this temporal solutions is
acceptable for the clients of out WS.
Still, I am going to rebuild axis to see if I can get rid of the logger
dependencies that create so much problems for applets. Of course, if
somebody knows an easier way or a shortcut, let me know :).
--Luis R.
From: Bjørn Magnus Mathisen <[EMAIL PROTECTED]>
Reply-To: [email protected]
To: [email protected]
Subject: Re: Axis and Applet coexistence?
Date: Thu, 14 Jul 2005 12:34:38 +0200
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hi
i'm currently working on a project heading in the same direction;
a applet running axis-osgi client SOAP calls.
i would be really interested in a source patch or something alike, if
you get this working :)
regards
Bjørn Magnus Mathisen
Telenor ASA R&D
Luis Rivera wrote:
> Thanks for the reply. I actually did. Using the allow all custom
> security manager that only overrides those two methods work fine
> when the applet is allowed to set a new security manager. But
> that's the problem, to allow the applet to do this I still have to
> add a couple of lines to the policy file or use a new one that has
> those permissions and is loaded when the applet is loaded too.
>
> I know that should not be a problem if I had complete control of
> what I can install and modify in the client. But in our case, I
> have been told that's a no no, I have to make and break axis to let
> it work in the sandbox What I don't understand is why not to alow
> an option in axis to prevent it from doing things like
> createClassLoader and that kind of stuff that is just prohibited in
> an applet. It works beautifully outside of the applet, no problem
> (ok, after loading and deploying the right stuff in the right
> place).
>
> Now I have to make it work in an applet, because the alternative
> cost $2000 bucks per client, so I have to make it work. If any of
> you have any advise that will make my task easier, I will greatly
> appreciate it :).
>
> Thanks again, --Luis R.
>
>
>> From: "Baker, Jay" <[EMAIL PROTECTED]> Reply-To:
>> [email protected] To: <[email protected]> Subject:
>> RE: Axis and Applet coexistence? Date: Wed, 13 Jul 2005 16:43:48
>> -0500
>>
>> Yeah, I don't think the sandbox is going to go for that. I'm
>> pretty sure that you can't give a policy file to your client in
>> an applet.
>>
>> Did you override #checkPermission (both methods - it is
>> overloaded) with a no-op? That's what worked for us ... along
>> with the signing of course.
>>
>> -----Original Message----- From: Luis Rivera
>> [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 13, 2005 4:04
>> PM To: [email protected] Subject: RE: Axis and Applet
>> coexistence?
>>
>>
>>
>> Hi,
>>
>> Well, it seems that with a custom security manager I still have
>> the problem of having to modify the security policy file to allow
>> the applet to use the new security manager. However, in my case I
>> don't think I can go into each axis client's machine to install
>> this new file.
>>
>> So, I want to ship it (custom policy file) with the cient jar
>> file and if possible upload it along the applet when it is loaded
>> by the browser. However I don't know how to do this, or even if
>> it is possible. It is possible to pass the policy file as a
>> parameters to the appletviewer, but how do you pass it when it is
>> loaded by the browser each time the applet is loaded?
>>
>> Thansk in advance for any help, --Luis R.
>>
>>> From: "Baker, Jay" <[EMAIL PROTECTED]> Reply-To:
>>> [email protected] To: <[email protected]> Subject:
>>> RE: Axis and Applet coexistence? Date: Mon, 11 Jul 2005
>>> 17:24:50 -0500
>>>
>>> That's what we did. We installed a custom security manager that
>>>
>> just grants
>>> access to all. YOu might run into other issues, but the sandbox
>>>
>> end of
>>> things should be solvable with this kind of an approach.
>>>
>>> -----Original Message----- From: Luis Rivera
>>> [mailto:[EMAIL PROTECTED] Sent: Monday, July 11, 2005 5:21
>>> PM To: [email protected] Subject: Axis and Applet
>>> coexistence?
>>>
>>>
>>> Hi all,
>>>
>>> I have been reading the posts regarding applets and axis. It
>>> looks
>> like
>>> there is a solution but I am not sure I understand how. I have
>>> a
>> signed
>>> applet and I even unpacked all the library jars files into a
>> single huge
>>> jar file, which I signed and I am using to start the applet.
>>> However, the LogFactory created by the Logging mechanisms is
>>> breaking the
>> applet ...
>>> seems like I need to either hack the library or to use a new
>>> security policy? ... would it be enough to use a custom
>>> security manager?
>>>
>>> Thanks in advance, --Luis R.
>>>
>>> _________________________________________________________________
>>> FREE pop-up blocking with the new MSN Toolbar - get it now!
>>> http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
>>>
>>
>> _________________________________________________________________
>> Express yourself instantly with MSN Messenger! Download today -
>> it's FREE!
>> http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
>>
>
> _________________________________________________________________
> On the road to retirement? Check out MSN Life Events for advice on
> how to get there!
> http://lifeevents.msn.com/category.aspx?cid=Retirement
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFC1j++QRm7yJAC45gRAj+4AJwO1QUKOYNXNhhNfaVP31w7+bWQ4gCfQEX2
Vi3RUZMKdFFZdDYxfk7znGA=
=ZAKU
-----END PGP SIGNATURE-----
_________________________________________________________________
Dont just search. Find. Check out the new MSN Search!
http://search.msn.click-url.com/go/onm00200636ave/direct/01/
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
