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 Fri, 28 Feb 2014 10:20:04 GMT
Thanks, I've fixed this on trunk.


On Thu, Feb 27, 2014 at 10:57 PM, <> 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:
> 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.
> Regards,
>    Detelin
> 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

Colm O hEigeartaigh

Talend Community Coder

View raw message