ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colm O hEigeartaigh <>
Subject Re: Potential memory leak when using wss4j in web application
Date Thu, 27 Feb 2014 16:45:01 GMT
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?


On Thu, Feb 27, 2014 at 4:39 PM, <> 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

View raw message