I'm assuming this means that the LifeCycleModule class loader and the
Applib class loader both have the Connector class loader as their
parent. I will comment this out for EA and uncomment it for final.
June
On 04/ 7/09 10:33 PM, Jerome Dochez wrote:
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>