Thanks for the detailed explanation. One question: Would developers
who are creating OSGi plugins to extend the app server need to know
about the Module class loader?
June
On 08/ 8/08 06:03 PM, Sahoo wrote:
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>