Kedar Mhaswade 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
>> 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?
>>
> Well, this CL is not available for Prelude since deploying of MBeans
> is not yet supported for Prelude. It will be available for v3 final,
> though.
Will the mbean class loader be in the same position in the hierarchy,
with the public API class loader as its parent?
Will the life cycle module class loader exist at all in V3?
June
>
> - Kedar
>
>> 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
>