There are several things that we could do here:
1) Keep and extend the debug console as noted below.
2) Eliminate it completely (possibly integrating the essential portions
into the web console.
3) Integrate it completely into the web console in it's own "area" of
the navigation. This could be completely hidden from the average
application administrator when we have extended the console with role
based filtering and permissions.
I prefer #2 & #3 over 1 because it seems confusing to have multiple
consoles and there will be some overlap between them. I'm also inclined
toward #3 rather than #2 because I don't yet have a user perspective on
how critical it is to have all of the current debug capability at the
MBean level.
However, for release 1 this it might be too ambitious to rewrite the
debug console into portlets and extend it with new capabilities in the
proposed time frame (especially since there appear to be more pressing
console issues to be resolved). Perhaps the best approach for release 1
is to ensure that the current capabilities are functional and nothing
more. Also, if we were do attempt #3 prior to including some type of
role based filtering the average user might find the additional JMX
functionality confusing. Thoughts?
- Joe
[EMAIL PROTECTED] wrote:
I'm working on the debug console;
looking for requirements feedback;
show all gbeans and dirll down to attributes and attribute info
show configurations
focus on selected configuration
show wars, ears, etc
show connection factories (jdbc, jms)
show security realms
basically we can show any type of object, such as web-containers,
servlets, etc
operations console: perform jmx operations
Simon
--
Joe Bohn
[EMAIL PROTECTED]
"He is no fool who gives what he cannot keep, to gain what he cannot
lose." -- Jim Elliot
