Some "simple" things.
Ability to "clone" resources (like connection pools where you just want to change the DB/user/PW).
Ability to export and import resources across domains. We run in to this a lot during development. You don't want to share the entire config.xml, but need something configured in someone elses instance, so you end up basically opening up two consoles and alt-Tab and cut-n-pasting stuff over. Something more formal would be nice.
I would like to see more wizards. I think the wizards would be a good opportunity to better educate users on what and why something is being asked for. For example, in the current JMS configuration, you need to enter the name of the queue. This suddenly changed late v2 process, before there wasn't a required field (it was expressed as a property). In fact it is still expressed as a property save when you create it (and before it was defaulted). But it's a wiggly loose link that connects the EJB JMS resource to the actual JMS implementation, and I know when I first saw it, I wasn't even sure what it wanted.
I think the console should be made extensible somehow, if possible. For example, I think that if you're going to support "all" of the databases (Oracle, MySQL, Postgres, SQL Server, etc.), I'd like to have a "first class" form for the specific parameters that database wants. But it would certainly be nice for other to be able to add "DB Modules" for their own database.
The key thing, I think (being a notorious practitioner of it my self) is that most folks get their "documentation" from the UIs, plain and simple. We grudgingly crack open the documentation, and you know that when we do we're going to stop the instant we think we find what we're looking for.
So, a combination of task based documentation and a task based UI takes folks a LONG WAY to making progress with the application server. Recall that for many folks, when the message says "talk to your system administrator", that person IS the "system administrator" and may well not be clear on what important bit of information they may be missing.
Wizards can help mitigate that while supporting a reference based UI for the "power user".
Frankly, the console is the key to adoption of Glassfish, as it's most users first experience with it outside of "Run Project" with NetBeans. So, it needs to be as robust and easy to use as possible. As we "simplify" EJB, so will we need to "simplify" the container. A lot of folks working with the container are going to get there via wizards and other easy to use artifacts that hide the real underlying complexities. But if they have to deal with the app server at the console level, perhaps one of those hidden complexities poked its ugly head out and caused a problem. All of a sudden some novice user finds themselves instantly flung down the rabbit hole trying to make sense of the stack traces and opaque error messages with a cold UI posing blank form fields the user has little idea how to fill.
So, overall, I think a combination of hand holding/wizards and topical explanations will make the GUI just that much better. Could perhaps be as little as a nice troubleshooting link in the GUI "I can't connect to my JMS queue..."
I think a "recent tasks" thing would be interesting, something that lets us "bookmark" the UI for things we may need to do commonly. "I know user logs are in here somewhere, but where did they go?"
[Message sent by forum member 'whartung' (whartung)]
http://forums.java.net/jive/thread.jspa?messageID=248346