On Mon, Jun 16, 2008 at 1:03 AM, Saminda Abeyruwan <[EMAIL PROTECTED]> 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/
