Community
Participate
Working Groups
Build Identifier: 2.2.0.v20101117-r8503 DefaultPersistenceProviderResolver has field like this: private volatile WeakHashMap<ClassLoader, List<PersistenceProvider>> providers = new WeakHashMap<ClassLoader, List<PersistenceProvider>>(); ... Collection<ProviderName> providerNames = getProviderNames(loader); loadedProviders = new ArrayList<PersistenceProvider>(); ... A WeakHashMap is used to avoid permanently holding a reference to user's class loader, but look at the value being stored there: it's an ArrayList<PersistenceProvider>, which means if the provider is loaded by user's class loader, it can never be garbage collected until the cache is cleared. Does anyone clear this cache? I don't think so. Why not change it to: WeakHashMap<ClassLoader, List<String>>, where in the value, we store discovered provider class names as opposed to provider instances. When a provider is required, one can then do ClassLoader.loadClass(providerName).newInstance(). Reproducible: Always
Setting target and priority. See the following page for the meanings of these fields: http://wiki.eclipse.org/EclipseLink/Development/Bugs/Guidelines
Created attachment 223245 [details] Proposed Fix
Fixed in EclipseLink 2.5.0 with Commit Id - dd616647431960dd929a6bc7bff54a71f988a7c1
Fixed in EclipseLink 2.4.2 with Commit Id - 645725ff8cfa0e8b3c4e2f934aa1669aef07d103
*** Bug 353155 has been marked as a duplicate of this bug. ***
Will this bug be officially announced that all JEE container vendors are aware that they have to update their javax.persistence.jar? Will the official JSR 317/338 JPA spec jars be updated accordingly? ( http://download.oracle.com/otndocs/jcp/persistence-2.0-fr-eval-oth-JSpec/ ) Otherwise this bugfix might not make into the application server's code - and chances are high that the leak will stay in these environments.
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink