dev@glassfish.java.net

Re: Question about ClassLoaderHierarchy#getAppLibClassLoader

From: Jerome Dochez <Jerome.Dochez_at_Sun.COM>
Date: Tue, 07 Apr 2009 22:33:51 -0700

yes nothing changes from v2 for the module lifecycles. we are still
reviewing the MBeans.

jerome


On Apr 7, 2009, at 12:21 PM, June.Parks_at_Sun.COM wrote:

> Was anything decided in this morning's meeting?
>
> June
>
> On 04/03/09 14:21, Jerome Dochez wrote:
>> interesting questions.
>>
>> let's talk about this at our next engineering meeting. Sahoo will
>> you be able to join ?
>>
>> jerome
>>
>> On Apr 3, 2009, at 10:00 AM, June.Parks_at_Sun.COM wrote:
>>
>>> Jan brings up the topic of class loaders to be added later. GFv2
>>> had MBean and LifeCycleModule class loaders that so far GFv3
>>> doesn't have. I've heard that the final v3 release will include
>>> MBeans and LifeCycle modules, so I'm wondering if there are going
>>> to be special class loaders for these, and if so, where they will
>>> be in the hierarchy.
>>>
>>> In v2, the MBean class loader has the same parent as the Common
>>> class loader and the LifeCycleModule class loader has the same
>>> parent as the Application (now Applib) class loader. Will this
>>> also be the case in v3?
>>>
>>> June
>>>
>>> On 04/02/09 20:14, Jan Luehe wrote:
>>>> Sahoo,
>>>>
>>>> given an app, we'd like to be able to query
>>>>
>>>> org.glassfish.internal.api.ClassLoaderHierarchy
>>>>
>>>> for the classloader that comprises the library JAR files passed
>>>> to the --libraries deploy command option during the app's
>>>> deployment.
>>>>
>>>> We noticed that in addition to taking an app name,
>>>> ClassLoaderHierarchy#getAppLibClassLoader also requires a list of
>>>> library URIs (corresponding to the JARs specified via --libraries)
>>>> as one of its arguments.
>>>>
>>>> We were hoping that passing the app name would be sufficient.
>>>>
>>>> Do you know how we can get to the List<URI> from any of the
>>>> artifacts
>>>> made available to com.sun.enterprise.web.WebApplication?
>>>>
>>>> Alternatively, we could navigate to [F] from [H] in:
>>>>
>>>> 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]
>>>>
>>>> but that would be error prone since additional classloaders may be
>>>> inserted into the chain sometime in the future.
>>>>
>>>> Thanks,
>>>>
>>>> Jan
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>