On Jan 31, 2008, at 11:08 AM, Lloyd L Chambers wrote:
> Jerome,
>
> Agreed, it's not directly related. I glommed onto the message as
> something related, not closely though.
>
> I just want to make sure that monitoring and runtime MBeans (and
> config) all agree on the right name as it caused me a lot of
> headaches implementing AMX in V2.
I see, yes they should all use the registration name... and use
categories for segregating them.
>
>
> Lloyd
>
> On Jan 31, 2008, at 9:52 AM, Jerome Dochez wrote:
>
>> Lloyd,
>>
>> that seems to be quite different from what Tim was trying to solve
>> (guessing a good name when the user is not providing one). Now what
>> was the issue exactly in v2 ? After deployment is finished, the
>> registration name is stored in the domain.xml, why was that not an
>> official way to get the app name ?
>>
>> Jerome
>>
>> On Jan 31, 2008, at 9:31 AM, Lloyd L Chambers wrote:
>>
>>> Tim,
>>>
>>> The name was a problem with developing the AMX MBeans in V2. So
>>> in V3, let's make sure there is an "official" way to get the
>>> runtime name for use with the JSR 77 MBeans, whose ObjectName will
>>> need to incorporate the app name.
>>>
>>> Lloyd
>>>
>>> On Jan 31, 2008, at 8:54 AM, Tim Quinn wrote:
>>>
>>>> Historically the default application name has been the name
>>>> (without file type) of the archive. In v3 up until now the
>>>> DeployCommand implemented this logic.
>>>>
>>>> Some application types, such as JBI service assemblies, will need
>>>> to vary from this. In fact JBI service assemblies were handled
>>>> as special cases in v2 autodeployment for just this reason.
>>>>
>>>> I have just checked in a small v3 change set that delegates the
>>>> selection of the default application name to the ArchiveHandler
>>>> for the relevant archive type. The default implementation in
>>>> AbstractArchiveHandler is functionally identical to what has been
>>>> the case in v2 and v3. The JBI service assembly archive handler
>>>> will be able to override this implementation to return the name
>>>> of the service assembly from inside the archive, as the special-
>>>> case logic for JBI in the v2 autodeployer does today.
>>>> Jerome correctly warns that the logic that determines an
>>>> archive's default app name should not rely on APIs provided by
>>>> the corresponding container because those APIs might not have
>>>> been loaded yet. In the JBI service assembly case the special-
>>>> case logic in the v2 autodeployer fetched the descriptor file
>>>> entry from the archive and used XPath to navigate to the data of
>>>> interest. The JBI service assembly archive handler will probably
>>>> do the same, thereby avoiding the illegal dependency Jerome
>>>> warned about.
>>>>
>>>> - Tim
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>
>>>
>>> ---
>>> Lloyd L Chambers
>>> lloyd.chambers_at_sun.com
>>> Sun Microsystems, Inc
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>
> ---
> Lloyd L Chambers
> lloyd.chambers_at_sun.com
> Sun Microsystems, Inc
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>