Hummm, didn't an EMF have to say "I need this class enhanced"? If so,
can't you remember which EMFs wanted that class enhanced, and when
they close, delete the reference? Alternatively, how about a weak
reference?
Specifically, this type of explicit API makes it difficult to
integrate with OpenJPA in a generic way. This is the same problem
that Commons Logging had until recently when they added a weak
reference to the class loaders.
-dain
On Jan 16, 2008, at 4:56 PM, Patrick Linskey wrote:
The problem is that the registration happens during class load, which
is unrelated to EMF closure.
-Patrick
On Jan 16, 2008 4:19 PM, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
I'm getting the following class loader leak from PCRegistry.
java.net.URLClassLoader
<loader> of org.apache.openejb.test.entity.cmp.ContextLookupCmpBean
pcSuper of org.apache.openjpa.enhance.PCRegistry$Meta
hard of
org.apache.openjpa.lib.util.concurrent.ConcurrentReferenceHashMap
$WeakEntry
[15] of
org.apache.openjpa.lib.util.concurrent.ConcurrentReferenceHashMap
$Entry[47]
table of
org.apache.openjpa.lib.util.concurrent.ConcurrentReferenceHashMap
_metas of org.apache.openjpa.enhance.PCRegistry
I noticed that PCRegistry does have a deRegister(classloader) method,
which I assume would release the resources, but I'm curious why the
resources aren't automatically released when I call EMF.close().
Is there anyway, we can have PCRegistry automatically release the
class references, so I don't have to call an OpenJPA specific api?
Thanks,
-dain
--
Patrick Linskey
202 669 5907
