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.
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