I like the idea, but @Alias is fairly generic, how about at least
@CmdAlias?
I've already run into an annoying problem with @Attribute (HK2) vs
Attribute (JMX).
On Mar 29, 2008, at 12:14 PM, Kedar Mhaswade wrote:
> Jerome Dochez wrote:
>> 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?
>> that's not really what I was suggesting, I think it's fine to keep
>> list-components as experienced glassfish users will rely on its
>> existence.
>>>
>>> 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
>> this is interesting apart from the fact it is stored on the local
>> file system. I see not good reason for that...
>> I think the two proposals are complementing each others, my way is
>> a System way of defining aliases, your proposal is a user/
>> installation way of customizing commands. I think we could do both
>> very easily.
>
> Yes, I agree. We should be able to register the *same command code*
> in different names. Since we might have multiple names, I suggest
> @Alias to accept a single alias or an array of aliases.
>
> Jane, I will work with you to fix list-components to be aliased
> as list-applications.
>
> The only "issue" I see is the aliases quickly become the "interfaces"
> of the product and we have to support them as server interface.
>
> If people agree, we can make this change and abide by the names.
>
> - Kedar
>
> ---------------------------------------------------------------------
> 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