The mailing list apparently didn't send this message properly. Resending...
-------- Original Message --------
Subject: Re: list-applications VS list-components
Date: Mon, 31 Mar 2008 13:27:04 -0700
From: Peter Williams <pete.williams_at_sun.com>
To: dev_at_glassfish.dev.java.net
References: <1133FCE8-CA5E-4D8C-ADEF-83E04D553B30_at_sun.com>
<47ED5F53.2080203_at_sun.com>
I haven't yet digested this change fully but it has caused a number of
problems with the NetBeans plugins as Ludo has already mentioned.
* All our NetBeans V3 plugins were broken by the manifest format
changes, so now we have table our other work and fix them ASAP.
* The format change was unannounced and unexpected. A heads up email
would have been nice. An "I need to change the format of this, is that
ok" email would have been even better. Didn't we just have this
discussion wrt/ deploy/redeploy changes a few weeks ago?
* Names now include extra appended data and will have to be parsed.
Parsing is computationally more expensive and fragile. One of the goals
of the Manifest format was to send machine readable data that didn't
need to be parsed. This goal is now been broken. Why?
* At first glance, it seems the path information for a directory
deployed module was removed. My code was depending on this (and in
fact, was told to depend on it when we had the big discussion about
deploy/redeploy). How do I find out what the path of a directory
deployed module is now?
* I'm told that now applications can reference multiple containers (in
the previous format this was not possible and my code was depending on
this constraint). Is this true? What does it mean and how do I
determine what the type of an application is if this can no longer be
inferred from the type of container?
-Peter
Jane Young wrote:
> Hi, Jerome.
>
> I added the list-components command and display the warning message in
> list-applications since we didn't want to support two commands that do
> the same thing. To be compatible with v2, we need to have the
> list-components command. But since there may be confusion with add-on
> components, maybe we should deprecate list-components command and
> officially support list-applications command instead of displaying a
> warning message that this command will be removed. What do you think?
>
> The ListApplicationsCommand.java is actually calling
> ListComponentsCommand.java so there is no duplicate code. I think
> adding @Alias would be nice.
>
> Kedar, Bryon and I actually came up with a proposal to allow user to
> create command aliasing using asadmin. See:
> http://wiki.glassfish.java.net/Wiki.jsp?page=ProvidingScriptsInBinFolder2HideDomains#section-ProvidingScriptsInBinFolder2HideDomains-CommandAliasing
>
>
> Let me know your thoughts.
>
> Thanks,
> Jane
>
>
> Jerome Dochez wrote:
>
>> so somehow we changed the list-applications into list-components and
>> issue warnings when doing a list-applications.
>>
>> can't we just alias the commands, seems to me that list-applications
>> is a *lot* more natural command name than list-components which
>> could soon be confused with add-on components related commands.
>>
>> I would love to see an official aliasing in place in the asadmin
>> adapter, maybe we could have a new annotation @Aliases
>>
>> so we could have something in that spirit
>>
>> @Service(name="list-components")
>> @Alias("list-applications")
>> pubic class ListComponentsCommand implements AdminCommand {
>>
>> }
>>
>> what do people think ?
>>
>> Jerome
>>
>> ---------------------------------------------------------------------
>> 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
>