I've been following this thread with interest - but silently until now.
Is there actually a need for the @Alias annotation? Can a single class
be defined as multiple commands by defining it to provide multiple
services, such as
@Service(names="list-applications,list-components")
public class ListApplicationsCommand implements AdminCommand {
or some equivalent syntax? (Two @Service declarations??)
I don't know the details of @Service - perhaps this is not permitted.
It seems to me that it might be useful to reuse or slightly extend an
existing annotation rather than introduce a new one if Service can take
care of this.
Just a thought.
- Tim
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
>