[prev in list] [next in list] [prev in thread] [next in thread]
List: webservices-general
Subject: Re: Potential memory leak when using wss4j in web application
From: Colm O hEigeartaigh <coheigea () apache ! org>
Date: 2014-02-28 10:20:04
Message-ID: CAB8XdGDazDaPzKFi+mLa=txXj9cwiCRCaE7pS7u9rXFW7xc_Mg () mail ! gmail ! com
[Download RAW message or body]
Thanks, I've fixed this on trunk.
Colm.
On Thu, Feb 27, 2014 at 10:57 PM, <detelinyordanov@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 <coheigea@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, <detelinyordanov@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
[Attachment #3 (text/html)]
<div dir="ltr"><div><br></div>Thanks, I've fixed this on \
trunk.<br><br>Colm.<br></div><div class="gmail_extra"><br><br><div \
class="gmail_quote">On Thu, Feb 27, 2014 at 10:57 PM, <span dir="ltr"><<a \
href="mailto:detelinyordanov@gmail.com" \
target="_blank">detelinyordanov@gmail.com</a>></span> wrote:<br> <blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>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:<br> <br><a \
href="http://svn.apache.org/viewvc/webservices/wss4j/trunk/ws-security-common/src/main/java/org/apache/wss4j/common/crypto/WSProviderConfig.java?view=markup#l129" \
target="_blank">http://svn.apache.org/viewvc/webservices/wss4j/trunk/ws-security-commo \
n/src/main/java/org/apache/wss4j/common/crypto/WSProviderConfig.java?view=markup#l129</a><br>
<br></div>I saw that WSSConfig adds a couple of other security providers but takes \
care to remove them if already present:<br><br><a \
href="http://svn.apache.org/viewvc/webservices/wss4j/trunk/ws-security-dom/src/main/java/org/apache/wss4j/dom/WSSConfig.java?view=markup#l382" \
target="_blank">http://svn.apache.org/viewvc/webservices/wss4j/trunk/ws-security-dom/src/main/java/org/apache/wss4j/dom/WSSConfig.java?view=markup#l382</a><br>
<br></div>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).<br>
</div>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.<br><br></div><div>
Regards,<br></div> Detelin<br></div><div class="gmail_extra"><br><br><div \
class="gmail_quote">On Thu, Feb 27, 2014 at 6:45 PM, Colm O hEigeartaigh <span \
dir="ltr"><<a href="mailto:coheigea@apache.org" \
target="_blank">coheigea@apache.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div dir="ltr"><div><br></div>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?<br>
<br>Colm.<br></div><div><div><div class="gmail_extra"><br><br><div \
class="gmail_quote"> On Thu, Feb 27, 2014 at 4:39 PM, <span dir="ltr"><<a \
href="mailto:detelinyordanov@gmail.com" \
target="_blank">detelinyordanov@gmail.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">
<div dir="ltr"><div><div><div>Hi everyone,<br></div> 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.<br>
<br></div>Thanks,<br></div> Detelin<br><div><div><br></div></div></div>
</blockquote></div><br></div><br clear="all"><span class="HOEnZb"><font \
color="#888888"><br></font></span></div></div><span class="HOEnZb"><font \
color="#888888"><span><font color="#888888">-- <br>Colm O hEigeartaigh<br><br> Talend \
Community Coder<br><a href="http://coders.talend.com" \
target="_blank">http://coders.talend.com</a><br>
</font></span></font></span></blockquote></div><br></div>
</blockquote></div><br><br clear="all"><br>-- <br>Colm O hEigeartaigh<br><br>Talend \
Community Coder<br><a href="http://coders.talend.com" \
target="_blank">http://coders.talend.com</a><br> </div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic