[weld-issues] [JBoss JIRA] Created: (WELD-570) Partial export of javasisst from Weld breaks other javasisst clients

[Harald Wellmann (JIRA)]

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