No.
Thanks,
Sahoo
June.Parks_at_Sun.COM wrote:
> 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
>>
>