Hi. Some interesting ideas. I do not think we can or should drop the HTML interface. It is very handy for administration on machines where you can not install a Java client app.
I don't want to stop you from creating a SOAP adapter to JMX, which is what is sounds like you want to build... go for it. But we can't replace the HTML adapter with it, though we should replace it with something better at some point... that thing sucks. --jason On Friday 24 May 2002 09:23 am, Frederick N. Brier wrote: > This is in regards to the MBean viewer on port 8082. Instead of using an > HTML interface, what if we made it a SOAP interface with a Java > Client? This could tie into JAAS security and limit access. I wrote a > similar GUI on another Java project. I don't want to cause anyone nausea, > but the UI was similar to Microsoft Management Console (MMC). Further, the > MBean or SessionBean that was acting as the SOAP service could act as a > broker for the same SOAP service running on every JBoss server in the > cluster. For those not familiar with it, the MMC has a tree control in a > pane to the left and the right pane is defined based on the tree node > selected on the left side. The tree child nodes at each level are > configurable, both by attributes such as "hostname", "domain"(JMX), > "service", "name", and "type" or fixed expressions or value lists. > > So the default which would look similar to now would be by "domain" name > attribute which would yield nodes such as "DefaultDomain", > "JMImplementation", or "jboss.deployment". > > You could also have multiple configurations to look at your beans > differently. For instance, if you had an MBean showing number of > transactions per second, the tree could show that MBean service at the top > node and then all the hostnames underneath it. So you could easily flick > from node to note looking for bottlenecks. Of course, with all of the data > as XML, you easily design new node/panel "handlers" that could display > charts, graphs, aggregate tables of performance data, etc. One could even > have the GUI plug into the MMC and become part of the standard Microsoft > operating environment <tee hee hee>. > > We could also have the nodes extend into the attributes of an MBean. For > instance, the Jetty MBean has a DeployedApplications attribute which is a > java.util.Iterator which can't be displayed. Wouldn't it be nice to be > able to have a table possibly with hyper-links to related MBeans? > > Another idea is how to provide better context help for the MBean > viewer. This idea uses XDoclet to generate an XML file that could be > bundled in the .jar containing the class files for the MBean. It would > strip the JavaDoc from the class and data members from the MBean > class. Instead of having a dialog pop up and say "MBean Attribute" you > have a description of what it is, as well as the MBean itself. This > information would be retrieved by the MBean Viewer SOAP service and > provided to the GUI. > > Thoughts? > > > Frederick N. Brier > Sr. Software Engineer > Multideck Corporation > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
