You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ws.apache.org by de...@gmail.com on 2014/02/27 17:39:05 UTC
Potential memory leak when using wss4j in web application
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
Re: Potential memory leak when using wss4j in web application
Posted by Colm O hEigeartaigh <co...@apache.org>.
Thanks, I've fixed this on trunk.
Colm.
On Thu, Feb 27, 2014 at 10:57 PM, <de...@gmail.com> 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 <co...@apache.org>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, <de...@gmail.com> 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
Re: Potential memory leak when using wss4j in web application
Posted by de...@gmail.com.
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 <co...@apache.org>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, <de...@gmail.com> 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
>
Re: Potential memory leak when using wss4j in web application
Posted by Colm O hEigeartaigh <co...@apache.org>.
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, <de...@gmail.com> 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