Please read this bug report:
https://glassfish.dev.java.net/issues/show_bug.cgi?id=5701
Remember that the v3 admin command architecture is extensible.
It's possible to add new admin commands without modifying the server
or the asadmin client.
The question then is, how should we handle access to man pages,
both for commands we ship with v3 and for commands that are added
to the server later?
I can see a few decision points and corresponding options:
Should the server be required to be up to access man pages for
remote commands?
1. If yes, should the user be required to provide correct authentication
information to access remote commands?
a. If yes, that's how it works today.
b. If no, it seems that we have a few options:
i. Provide access to man pages, either through remote commands
or as raw html, on another port that is configured for no
authentication.
ii. Provide access to man pages, either through remote commands
or as raw html, on another URL that is configured for no
authentication.
iii. Use some sort of role-based access control to limit what
an unauthenticated user can do using the existing asadmin
remote commands.
2. If no, do all man pages need to be available when the server is
down, or only some subset of the man pages (e.g., for the commands
that have previously been executed)?
a. If all, we would need to package all the man pages with the client,
probably with a fallback to access the server if the man page can't
be found locally. There would also need to be a way for a third
party to provide local copies of man pages for remote commands;
providing them as resources in CLASSPATH should be sufficient.
b. If some, we could download the man page for a command on first
use of the command and cache it locally so that it's available
when the server is offline. The trickiest issue is detecting
when the cached man page is invalid.
Does anyone else see any other options or approaches?
The status quo is "1a". The bug report argues for "1b" or "2".
What choice do people prefer?