ws-dev mailing list archives

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


View raw message