The list-secure-admin-principals and list-secure-admin-internal-users commands both incorrectly prompt for a command operand. In contrast, they should not – these commands should list all of the respective elements.
The problem is that I incorrectly specified a resolver for the two list commands in the CRUD notation.
This is certainly not a show-stopper for 3.1.1 release. Relatively few users will create secure admin principals or secure admin internal users, so few will need to list them. As a workaround, users can use
asadmin get secure-admin.secure-admin-principal.*
asadmin get secure-admin.secure-admin-internal-user.*
In both cases, if no such items are defined then the user gets a message like this:
remote failure: Dotted name path secure-admin.secure-admin-internal-user.* not found.
Command get failed.
which is ugly but it conveys correct information.
I have marked this for review in case others feel strongly that this is in-your-face enough to warrant a fix at this point.
Why fix this issue in 3.1.1?
Although there is a workaround, the error is very in-your-face.
Which is the targeted build of 3.1.1 for this fix?
If approved, b11.
Do regression tests exist for this issue?
Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
Tests involving enabling secure admin; the CRUD list functionality should be fully insulated from other code paths.