June.Parks_at_Sun.COM wrote:
> 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
V2 description was clearly wrong. The parent of shared chain was never
system class loader. System class loader in JDK means the class loader
that JVM creates using -classpath arguments supplied on command line.
So, v2 should be changed to extension.
> shared chain public API
Correct.
> common common
> connector connector
> application applib
No, they are not comparable. application class loader is much larger in
scope than applib class loader. applib class loader is a class loader
per application that has all the deployed libraries that the application
depends on using --libraries option while deploying.
> web modules
Wrong comparison. You can omit this from user documentation, we don't
want users to know about this. That's only used by special applications
like admingui.
> JSP engine archive
>
Wrong comparison. JSP engine class loader should not be exposed to user.
All they should care about is a class loader that can load classes from
their 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?
They will be introduced as time progresses.
Thanks,
Sahoo
>
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>