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
>