Thanks, I've fixed this on trunk. Colm.
On Thu, Feb 27, 2014 at 10:57 PM, <[email protected]> wrote: > We are using wss4j 1.6.5, I had a quick look at the latest code and it > seems that it still registers the provider only if it is not already > available: > > > http://svn.apache.org/viewvc/webservices/wss4j/trunk/ws-security-common/src/main/java/org/apache/wss4j/common/crypto/WSProviderConfig.java?view=markup#l129 > > I saw that WSSConfig adds a couple of other security providers but takes > care to remove them if already present: > > > http://svn.apache.org/viewvc/webservices/wss4j/trunk/ws-security-dom/src/main/java/org/apache/wss4j/dom/WSSConfig.java?view=markup#l382 > > I'm considering another solution to the issue that does not require any > changes in wss4j, namely to unregister the XMLDSigRI provider in our > servlet's destroy method. This can be done only if the provider was > registered by the webapp (checking if provider's classloader is the > webapp's classloader). > The benefit is that the provider is always unregistered when the webapp is > undeployed, so it would prevent any memory leaks. But the downside is that > the servlet is to some extend coupled with wss4j. > > Regards, > Detelin > > > On Thu, Feb 27, 2014 at 6:45 PM, Colm O hEigeartaigh > <[email protected]>wrote: > >> >> What version of WSS4J are you using? I believe that this has already been >> fixed. Can you try with the latest version of WSS4J 1.6.x? >> >> Colm. >> >> >> On Thu, Feb 27, 2014 at 4:39 PM, <[email protected]> wrote: >> >>> Hi everyone, >>> We have a web application using wss4j (through Axis2 web services >>> runtime) which gets deployed on Tomcat and in certain scenarios we were >>> getting ClassNotFoundExceptions or ClassCastExceptions when invoking web >>> services secured with wss4j. These surfaced when the web service is invoked >>> once, the web application is re-deployed and the web service is invoked >>> once again. Upon closer investigation, we figured that this is ultimately >>> caused by wss4j registering the XMLDSigRI security provider once and not >>> re-registering it if it is already available. So in our case, the XMLDSigRI >>> provider is registered on first deploy of the webapp and when the webapp is >>> re-deployed, the newly initialized wss4j classes would still use the >>> previously registered provider. This causes ClassNotFoundExceptions when >>> the web services was not executed before redeploying the webapp, since >>> Tomcat would cleanup the webapp classloader as much as it can and would not >>> be able to load additional classes. If the web service was executed before >>> the re-deploy, a ClassCastException is thrown since the previously loaded >>> classes conflict with the newly loaded ones. The issue is easily resolved >>> by changing wss4j's WSSConfig to remove any previously registered XMLDSigRI >>> provider, but I wonder whether this is the correct approach, since the >>> provider might be registered already by another WSSConfig instance (in >>> another class loader).. The other solution is to move wss4j library out of >>> the webapp and into the Tomcat lib folder, so no re-registration is needed >>> anymore (this might require moving additional libraries, e.g. xmlsec as >>> well). Did anyone experience similar issue with wss4j before? If anyone >>> has, please share any pointers on what is the preferred approach to fix >>> this. >>> >>> Thanks, >>> Detelin >>> >>> >> >> >> -- >> Colm O hEigeartaigh >> >> Talend Community Coder >> http://coders.talend.com >> > > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
