Hi, Matthias
> yes it's still the same.
> I let GF run for 3 hours - the stack trace was still the same so I
> killed the process.
> 3 hours for that EAR and still not finished!
>
> I'll try the directory deployment on Monday.
Actually no need to try that anymore. :-) I had some discussions with
the connector team this morning (this stack trace is from the connector
code) and there are a couple optimizations we can make. And in the ear
case, we will be able to eliminate this part of the annotation scanning
completely. There might be some other bottlenecks down the road, but at
least this stack trace should disappear for ear case.
I have done some initial testing on the changes and doing some more
testing now. I plan to check in this change later today. If you could
grab a nightly build once I check in the change, it will be great. The
HCF is next week which means we need to be very careful with the changes
we check in afterwards (only show stopper can go in, this is to make
sure we have a stable build). So if you can try this at your earliest
convenience once the change is available in the nightly build, it will
be very helpful for us in case there are other issues discovered and we
need to address those as well.
Thanks,
- Hong
>
> Hong Zhang schrieb:
>
>> Hi, Matthias
>> Is the stack trace still the same?
>> Unfortunately all the libraries need to be scanned as the component
>> annotations could exist in anywhere. However, the scanning takes much
>> longer when the archive is a jar and not a directory. You could try
>> to use directory deployment to see if things improve a little bit
>> (see this link for some details on directory deployment, the link is
>> for v2.1 but still applicable to v3) The directory deployment
>> directory layout would be something like this (the sub directory also
>> needs to be in a directory format):
>> foo/
>> foo_war/
>> foo_jar/
>>
>> In the meantime, we will look for other ways to improve the situation.
>>
>> Thanks,
>>
>> - Hong
>>
>> matthias.fraass_at_tricoder.net wrote:
>>
>>> I have a question about Tims comment on the bug:
>>>
>>> "This might not resolve the problem completely, because annotation
>>> detection does need to look at all the .class entries in the JAR."
>>>
>>> Does this apply only for the ejb.jar or all WARs and JARs of the EAR?
>>> Also for the jars in the lib-directory of the EAR
>>> (<library-directory>)?
>>>
>>> If there are jars that are not scanned by GF, I could move all non-JEE
>>> classes from the ejb.jar to a different jar, as a workaround.
>>>
>>> -Matthias
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: quality-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: quality-help_at_glassfish.dev.java.net
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: quality-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: quality-help_at_glassfish.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: quality-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: quality-help_at_glassfish.dev.java.net
>