Hi Tom,
I agree, your change affects only Java SE deployment.
Do you have any kind of test that shows the result of optimization done
in TempClassLoader? An additional reading of XML file might negate the
class loading optimization that is put in place in TempClassLoader to a
large extent. If you have some numbers showing improvement in
performance, then that will help when I try to address
https://glassfish.dev.java.net/issues/show_bug.cgi?id=1147.
Also, there are other optimizations that can be done. We can set up
application class loader as TempClassLoader when WEAVING = false and in
such a case, we will avoid creating TempClassLoader and there by
executing the method you have added. Do you agree? Should we file an RFE
for this?
Thanks,
Sahoo
Tom Ware wrote:
> Hi Sahoo,
>
> I believe this change will only affect an SE deployment. We only
> call this method from our JavaSE initialization code. It is used to
> build a set of classes used to optimize the Temporary Class Loader we
> use in SE.
>
> So in answer to your question, yes, we will process files more than
> once, but it will only occur in SE deployments, and I am not sure it
> is really avoidable as long as we are optimizing the Temp class loader
> the way we are.
>
> As a result, I do not think 1115 needs reopening.
>
> What do you think?
>
> -Tom
>
> Sanjeeb Kumar Sahoo wrote:
>
>> Hi Tom,
>>
>> I have not run any test to validate what I am writing here, but I
>> thought I should let you know any way. I now see a new method called
>> *private static Set<String>
>> buildPersistentClassSetFromXMLDocuments(PersistenceUnitInfo,
>> ClassLoader)* in PersistenceUnitProcessor class. This method creates
>> a MetadataProcessor and reads all the mapping XML files in order to
>> build a list of classes and throws away the MetadataProcessor. As a
>> result of this change, are we not reading XML mapping files more than
>> once? Shall I reopen
>> https://glassfish.dev.java.net/issues/show_bug.cgi?id=1115 ?
>>
>> Thanks,
>> Sahoo
>>
>>