Sahoo wrote:
> Jan,
>
> Jan.Luehe_at_Sun.COM wrote:
>
>> Sahoo,
>>
>> just to confirm: Even though the classloading hierarchy in V3 is now
>> similar to V2, any user JAR files dropped in any of the locations
>> where they will be picked up by a designated classloader (i.e., any JAR
>> files dropped inside domains/domain1/lib will be picked up by the
>> common class loader) must have been OSGi-fied in order to explicitly
>> export their packages and become visible to any classloaders further
>> down in the delegation chain, right?
>
> No, we don't require jars placed in domain_dir/lib/ext, lib,
> domain_dir/applib, or domain_dir/lib to be OSGi-ed. That's what I
> meant by behavior similar to V2.In fact, user can place classes in
> exploded form in domain_dir/classes as well.
Thanks, Sahoo! This is great news!
Jan
>>
>> I'm asking because there used to be an issue with with tomcat-ajp.jar
>> not being picked up until you turned it into tomcat-ajp-osgi.jar, and
>> now someone filed this P1 about log4j.jar dropped in
>> domains/domain1/lib not being visible to his webapp:
>>
>> https://glassfish.dev.java.net/issues/show_bug.cgi?id=5433
>> ("Classloading issues for jars located in domain lib")
>
> Can we ask user to try latest nightly build?
>
> Secondly, every module owner has to do do some work to provide
> isolation between class loader and server environment. See:
> https://glassfish.dev.java.net/issues/show_bug.cgi?id=5385
>
> Thanks,
> Sahoo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>