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
>