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?
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")
Jan
Sahoo wrote:
> I have put back changes that allows us to have similar behavior like
> GF v1 or v2 with regards to application class loading. Given below is
> the relevant portion of my check-in comments [1]
>
> As discussed in the OSGi/V3 one-pager, application class loader
> in v3 behaves very similarly to v2, with the exception that not all
> server
> classes are visible. Only classes exported by implementation bundles for
> public use are available to application class loader. The hierarchy
> looks like
> this:
>
> archive class loader [H]
> -> Modules class loader [G]
> -> applib class loader [F]
> -> connector class loader [E]
> -> common class loader [D]
> -> public API class loader [C]
> -> extension class loader [B]
> -> null (a.k.a. bootstrap class loader) [A]
>
> Description of each element of the above delegation chain is given below:
>
> A. null: This is the bootstrap class loader of JRE. loads classes from
> rt.jar.
>
> B. extension class loader: It is JRE supplied class loader. Takes care of
> installed extensions (i.e. java.ext.dirs).
>
> C. public API class loader: It makes available all classes specifically
> exported by OSGi bundles installed in the runtime. This typically
> includes,
> but not limited to, Java EE APIs and other GlassFish APIs that we want
> applications to have access to. Currently, our OSGi bundles pretty
> much expose
> every package for public use. This should be fixed as described in
> https://glassfish.dev.java.net/issues/show_bug.cgi?id=5385.
> This class loader is implemented as a class loader of a OSGi bundle which
> has following import statement:
> DynamicImport-Package: *
>
> D. common class loader: This is responsible for making available
> libraries and
> classes installed in following places (in the order mentioned below):
> domain/lib/, domain/classes/, domain/lib/
>
> E. connector class loader: This is responsible for making standalone
> connectors
> available to deployed applications. It is written such that we can easily
> implement the new recommendation of Java EE 6 spec, which says a
> container
> should only make those standalone RARs available to applications that
> applications specifically depend on.
>
> F. applib class loader: Respondible for taking care of scoped
> libraries. These
> are libraries that an application depends on by specifying --libraries
> option
> during deployment.
>
> G: Modules class loader: This has visibility to all OSGi bundles that
> an application specifically requests access to either using
> HK2-Import-Bundles
> header or GlassFish-Requires-Service headers in manifest.mf. I strongly
> discourage using those techniques.
>
> H. archive class loader: Responsible for loading classes from application
> archive.
>
> This hierarchy is pretty similar to what we have in v2:
> http://docs.sun.com/app/docs/doc/819-3659/beadf?a=view
>
> To get hold of various elements of the hierarchy, a new API has been
> introduced in internal-api module called ClassLoaderHierarchy.
>
> Thanks,
> Sahoo
>
> [1]
> http://fisheye4.atlassian.com/changelog/glassfish-svn/trunk/v3?cs=21565
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>