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