Tim,
You assume my concern correctly.
In V2 names were used inconsistently--config used one name and
monitoring used another, making ObjectNames quite difficult to relate
to each other (programmatically at least, "foo_app" and "foo" are
completely different!). My concern is just seeing one algorithm use
to obtain the application name when an ObjectName needs to be generated.
Lloyd
On Jan 31, 2008, at 9:55 AM, Tim Quinn wrote:
> Hi, Lloyd.
>
> I should have made clearer that what I described is appropriate
> only during deployment of the application, and applies only to
> getting the default name of the application from the archive
> handler at that time. The user or other deployment client can, as
> before, specify a name explicitly, in which case the new mechanism
> for retrieving the default application name will not even be used.
>
> Your concern, clearly a valid one, seems to apply more to obtaining
> the actual name of the application, regardless of whether it was
> assigned explicitly or implicitly during deployment, while
> preparing the MBean. Even though off the top of my head I'm not
> sure of the details, I'd expect that at the time the MBean is being
> constructed - one of possible several places the application name
> is needed - that there is abundant information including the name
> available.
> - Tim
>
> 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