ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Potential memory leak when using wss4j in web application
Date Thu, 27 Feb 2014 22:57:29 GMT
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

I saw that WSSConfig adds a couple of other security providers but takes
care to remove them if already present:

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.


On Thu, Feb 27, 2014 at 6:45 PM, Colm O hEigeartaigh <>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, <> 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