Sahoo,
"Similar" is a relative term. The V2 and V3 class loaders have
different names, and appear to have somewhat different functionality.
There also appear to be two V2 class loaders that are missing. Here is
a comparison:
V2 Class Loaders V3 Class Loaders
bootstrap boostrap
system extension
shared chain public API
common common
connector connector
application applib
web modules
JSP engine archive
V2 also had the mbean class loader (parent shared chain) and the life
cycle module class loader (parent connector). Are these going away for
V3? If so, where will mbean and life cycle module classes be loaded?
June
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?
>
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>