axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nandana Mihindukulasooriya" <nandana....@gmail.com>
Subject Re: Extensions to Axis2/Java deployment engine
Date Sun, 15 Jun 2008 19:48:13 GMT
On Mon, Jun 16, 2008 at 1:03 AM, Saminda Abeyruwan <samindaa@gmail.com>
wrote:

>
> The reason Rampart jars need to go in to Axis2 lib is the Sun Service
>> Provider Interface problem. rampart-core.jar and rampart-policy.jar
>> registers some assertion builders using Sun SPI and those builders to be
>> used by neethi factory classes they should be in the classpath of those
>> neethi classes. So the only solution we have right now is to put those two
>> jars in the Axis2 lib. Actually we only need those two jars (not the third
>> party jars) to be in the Axis2 lib and rampart-trust.jar and other third
>> party jars can be bundled in the module itself. Can this be solved by OSGi ?
>> ( With the very little knowledge OGSi bundle classpath resolution and bundle
>> wiring , I couldn't figure out how to do this :( )
>>
>> Yes it is.
>
> Thank you!
>
> Saminda
>
> ps: wouldn't wss4j needed to be in root lib as well.
>

Nope, in the password callback case, WSS4J explicitly load the password
callback from the class loader of the service. So what WSS4J does is it asks
from the service class loader to provide the password callback (not from the
module class loader or class loader of WSS4J class ) .  So wss4j jar can be
bundled with the Rampart mar. Password callback class only need to be
available on the service class loader.  And WSS4J has nothing to do with
policies and it doesn't register any builders using Sun SPI.

thanks,
nandana

-- 
Nandana Mihindukulasooriya
WSO2 inc.

http://nandana83.blogspot.com/

Mime
View raw message