>>>> 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.
>
> Even though CLI, GUI and IDE doesn't change the enabled attribute of
> application, we can never stop user to hand edit that. In GUI, i
> always look at both. I suggest to check this also as it should be
> pretty straight forward.
I see. We may want a different name for this command then. Any suggestions?
>>>> 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.
>
> Great.
>
> thanks
> Anissa
>
>>
>> - 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
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net For
> additional commands, e-mail: dev-help_at_glassfish.dev.java.net