Hi Jerome,
I think we are currently creating only following two class loaders and
not three.
1. Created by the DOL to load the application (say "AppClassLoader")
This is the one that PersistenceUnitInfo.getClassLoader() will return.
2. A logical clone of above class loader created by
PersistenceUnitInfoImpl to service
PersistenceUnitInfo.getNewTempClassLoader().
I think the main issue as things are implemented today is - it is
possible that the DOL might load one of the persistence classes using
AppClassLoader to scan for annotations before the persistence provider
gets a chance to register ClassFileTransformer. Hence the byte code
enhancement desired by the persistence provider on that persistence
classes would never materialize.
I think your proposal will solve the above issue.
> 2. the classloader that was used to populate the DOL is not the
same as the one used to load the classes in the container (3rd class
loader)
> which is an issue since on the DOL, we store information like
> the Method object related to security artifacts and such...
> 3. the classloader on the DOL is not reset hence we keep reference
to at least 2 classloaders during the lifetime of the application.
I don't think we have above issues as things are implemented today. Am I
missing something?
>Sahoo/Mitesh : how would that impact the Java SE path ?
JavaSE is a different path than above hence we do not have any of the
above issues. :)
Thanks,
Mitesh
Jerome Dochez wrote:
> Hi All
>
> This will be a long email so bear with me...
>
> Talking with Mitesh, I discovered that we process persistence units
> too late in the application deployment/loading. The issue is that
> today, we do the following :
> - open the archive
> - process Java EE annotations (non persistence ones)
> - load XML
> - optional step : deployment
> - load application in ejb container which trigger
> + load persistence units with a new classloader
> (getNewEjbClassLoader API)
> + process @Entity entities
> + create a new classloader with the provided ClassTransformer
> + reload the enhanced application classes.
> - run the application.
>
> This is incorrect because :
> 1. we create 3 class loaders when loading
> 2. the classloader that was used to populate the DOL is not the
> same as the one used to load the classes in the container (3rd class
> loader) which is an issue since on the DOL, we store information like
> the Method object related to security artifacts and such...
> 3. the classloader on the DOL is not reset hence we keep reference
> to at least 2 classloaders during the lifetime of the application.
>
> We got lucky up to now because most @Entity classes do not use other
> Java EE annotations and this did not trigger failures but it is an
> unacceptable assumption.
>
> It seems to me we need to change the way persistence units are loaded
> in the application server to the following :
>
> - open the archive
> - create a temp class loader
> - find all persistence units and initialize the PersistenceProvider
> with each of them and get the ClassTransformer from the provider
> - initialize a new ClassLoader with the ClassTransformer to use
> from now on
> - process Java EE annotations
> - load XML
> - (deployment)
> - load applications.
>
> When there are no persistence units in the deployment artifact, we
> skip 2, 3 and 4
>
> Sahoo/Mitesh : how would that impact the Java SE path ?
>
> This way we create only 2 class loaders (one to load the unchanged
> classes, one to load the bytecode enhanced ones) . More importantly.
> we ensure that the class used by the Java EE annotation processor and
> deployment are the *final* class as they will be run in the EJB
> container.
>
> Also a number of APIs on the PersistenceProvider interface like
> getManagedClassNames() could allow us to plug my annotation scanner
> enhancement to avoid loading extra classes when we know they do not
> contain interesting annotations. I can work this out with Sahoo and
> Mitesh.
>
> Let me know if I missed anything.
>
> Thanks, Jerome
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>