Seems pretty silly to me to add such commands when they are
essentially methods which could be invoked on a utility MBean.
Doesn't scale.
Lloyd
On Apr 3, 2009, at 6:14 AM, Hong Zhang wrote:
> The two commands I needed so far for JSR88 (I am still working on
> JSR88 support, so there might be more):
> 1. ListAppRefsCommand: for a given target, find all the enabled
> modules, find all the disable modules, find all the available modules
> 2. GetHostAndPortCommand: for a given target, with a given module
> id, or a given virtual server, find the host and port of its
> associated non-secure http listener, find the host and port of its
> associatd security http listener.
>
> While it's possible to use the dotted name commands from client side
> to get the above information, it will be very cumbersome to do it
> from the client side. For example, for the first ListAppRefsCommand,
> two options I see if I use dotted name commands:
> 1. Use the dotted name list command to get all the application-refs
> under that target. And then for each application-ref, use the dotted
> name get command to get the enable attribute and check whether it's
> true. This option will cause many round trips between client and
> server.
> 2. Use the dotted name get command with wildcard, so I get all the
> application-refs under that target along with all their attributes
> in one request. Then the client would need to parse the returning
> result which contains a lot of information.
>
> And it would be more cumbersome to use dotted name for the
> GetHostAndPort, as there will be a bigger block of the information
> of the domain.xml (the whole http-service element as I need to look
> at http-listener and virtual-server) to deal with to find the result.
>
> - Hong
>
> Bill Shannon wrote:
>> Can we have some sort of architectural review of all the private
>> commands
>> to make sure they're not doing something that we *should* support
>> along
>> with our other commands?
>>
>> Jerome Dochez wrote:
>>> Hi All
>>>
>>> Hong asked me if we could add the ability to have private commands
>>> to v3. Private commands are remote commands that can be used by
>>> our tools like jsr88client, IDE tools, and GUI but users would not
>>> have access to using the normal CLI client. The point is not to
>>> protect or securely prevent commands to be executed by random
>>> users, it's simply about obfuscating them so users don't access
>>> them innocently as they won't be supported across releases. Please
>>> note that the current mechanism could be extended to secure
>>> invocations but I think it's an overkill at this point.
>>>
>>> I have just added the feature so to define a new private command
>>> you just need to annotate your AdminCommand implementation with
>>> @Visibility annotation and let the system do the rest.
>>>
>>> example :
>>>
>>> @Service(name="my-private-command")
>>> @Visibility(Private.class)
>>> public class MyPrivateCommand implements AdminCommand {
>>> ...
>>> }
>>>
>>> So far there are only two types of visibility defined in the system
>>>
>>> @Visibility(Public.class)
>>> @Visibility(Private.class)
>>>
>>> we could add more to bind commands to even stricter clients like
>>> for instance @Visbility(MySuperTool.class) but I don't think we
>>> will have to go that far. If you don't annotate your AdminCommand
>>> implementation it gets the default visibility of Public.
>>>
>>> If you try to invoke a private command from the asadmin CLI, you
>>> will get a disappointing result but feel free to try. Private
>>> commands are available on a different context root than the one
>>> used by the CLI.
>>>
>>> Let me know if you have any questions.
>>> ---------------------------------------------------------------------
>>> 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
>>
>
Lloyd Chambers
lloyd.chambers_at_sun.com
GlassFish Team