Partial export of javasisst from Weld breaks other javasisst clients
--------------------------------------------------------------------
Key: WELD-570
URL: https://jira.jboss.org/browse/WELD-570
Project: Weld
Issue Type: Bug
Components: OSGi support
Affects Versions: 1.1.0.BETA1
Reporter: Harald Wellmann
weld-osgi-bundle.jar (as used in Glassfish 3.0 and higher) still contains a
buggy version of javasisst causing memory leaks.
See WELD-453 and JASSIST-104. Even though Weld itself no longer uses the
problematic javassist ProxyFactory, it is still the root cause for a memory
leak occurring when HIbernate (or potentially any other Javassist client) is
used on Glassfish.
The problem exists in Glassfish 3.0.1 and also in the promoted build 3.1-b12
using a 1.1.0 prerelease of Weld, see
https://glassfish.dev.java.net/issues/show_bug.cgi?id=12368
weld-osgi-bundle.jar contains a version of javassist which is almost but not
fully private. There is a package export for javassist.util.proxy. When
deploying a WAR on Glassfish containing Hibernate (3.5.3) and another copy of
Javasisst required by Hibernate, then by parent classloader delegation
Hibernate will end up using the javassist ProxyFactory from Weld, registering
its proxies deep down in the container, and thus causing a memory leak with
each redeployment of the WAR.
Weld should either keep its included version of javassist fully private or
import all of javasisst via Import-Package, relying on javasisst installed in a
separate bundle.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
weld-issues mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/weld-issues
