dev@glassfish.java.net

Re: [v3] Change in where default application names are computed

From: Tim Quinn <Timothy.Quinn_at_Sun.COM>
Date: Thu, 31 Jan 2008 11:55:16 -0600

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
>