Hi, Anissa
>> 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
>
> Does the enabled status of these modules take into account the enable
> attributes in <application>, so we don't need to get that info from
> <application> and do the math ?
As in v2, the enable attribute of application is always set to true for
developer profile, so we only check the application-ref here. We can
enhance this as needed when cluster profile is implemented.
>> 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.
>
> Does it take into account the state of the virtual server (on, off,
> disabled) and the enabled status of the http-listener to create such
> list ?
>
Yes, this command has similar logic as the getHostAndPort APIs in
ApplicationsConfigMBean in v2.
- Hong
>>
>> 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
>>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net For
> additional commands, e-mail: dev-help_at_glassfish.dev.java.net