Thanks for posting.
Some notes/questions:
* Can ssh provisioning be enhanced to execute the asadmin "create-service" command to tie into native OS lifecycle services? Since we don't have a nodeagent in 3.1, this would be extremely useful. Of course, it would also require a GUI / CLI capability as well (different 1-pagers). It would also require the correct privileges on the remote host.
* +1 on username/password authentication (and its correct low priority). Based on your description, a consistent username/password would have to be used across all remote hosts (a valid limitation). While you mention asadmin and --passwordfile, I think a GUI would also be extremely useful since I see this username/password approach use case primarily for evaluation/demo use (perhaps an update center module). We wouldn't have to support this approach for production deployments unless we received lots of feedback requesting otherwise.
* Regarding section 7.0, I see the use case of a local node also as a(n important) demo/evaluation feature. Running the DAS and a "node" on the same OS breaking best practices unless some kind of resource management software is used to guarantee the DAS CPU/RAM/DISK service at a higher priority. In fact, a warning message to this effect would be good, such as: "WARNING: When running the Domain Administration Server and a GlassFish instance on the same host, ensure the Domain Administration Server is not starved for CPU, Memory, and Disk resources".
Otherwise, looks good!
[Message sent by forum member 'jclingan']
http://forums.java.net/jive/thread.jspa?messageID=472678