dev@glassfish.java.net

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

From: Lloyd L Chambers <Lloyd.Chambers_at_Sun.COM>
Date: Thu, 31 Jan 2008 09:31:05 -0800

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