Mitesh Meswani wrote:
> 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().
yes I should have been more precise, we create only 2 but that's pure
luck we manage to load the enhanced class with the class loader since it
seems the @Entity classes were not previously loaded. To make the
current behaviour "work", we would need a 3rd class loader to ensure we
load the bytecode enhanced vesions.
>
> 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.
right
>
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>