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.
>
> 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