Hello Hong,
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.
-Matthias
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
>