Hong Zhang wrote:
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.
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.
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@glassfish.dev.java.net
For additional commands, e-mail: dev-help@glassfish.dev.java.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: dev-help@glassfish.dev.java.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: dev-help@glassfish.dev.java.net