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
>