geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sing Li (JIRA)" <>
Subject [jira] Created: (GERONIMO-663) Request to improve Geronimo's JMX support for remote management systems
Date Sun, 05 Jun 2005 18:58:40 GMT
Request to improve Geronimo's JMX support for  remote management systems

         Key: GERONIMO-663
     Project: Geronimo
        Type: Improvement
  Components: general  
    Versions: 1.0-M4    
    Reporter: Sing Li
    Priority: Minor

The remote JMX support on Geronimo works amazing well.

Because of this, it also painfully reveals the tightly 
coupled heritage between Geronimo core and local
JMX based management/debugging tools.

Unfortunately, this is not good for remote management.

In particular, consider the topology where a bank of 
Geronimo servers may be managed via a single 
third-party management console. The same console 
may also manage a large number of non-Geronimo 
servers and assorted hardware. In order to "fit in" , 
the attributes and operations exposed through Geronimo 
should conform to the capability of the 

The following are some suggestions/guidelines that can 
make the server more friendly to remote JMX management 

1. Attributes with primitive types such as int, long, boolean, etc. 
should be exposed via their wrappers Integer, Long, Boolean, etc. 
In general, for maximal compatibility with remote JMX management 
systems, expose attributes with only the types described in the JDK 5
javadoc for

2.  Attributes with custom Geronimo specific-type should not be exposed. 
 Currently, there are attributes with type as complex as:


Remote JMX systems may need the entire Geronimo build 
to resolve all of the inter-dependencies; even if they
manage to do this, they will not know what is meaningful
to display to the management user for these attributes.

Such attribute is better exposed as a String typed 
attribute that summarize its current state or value.

3. Attributes that are intrinsically date values should be exposed as Date, 
and not as Long (or worse, long).

4. There are many attributes (such as classPath and dependencies) that are exposed 
currently as either java.util.List, java.util.URL, or  These should be exposed

as a simple String attribute that concatenate or pre-format the relevant information.

5. Last but not least, there exists almost no exposed attribute that changes dynamically 
in value with time. 

This is unusual, because such intrumentation is frequently used in trouble-shooting and 
performance tuning of servers. 

Instead of using alternate means, one may want to consider exposing them through 
JMX - and viewing the status via remote consoles, stats aggregators, etc.

The highly desirable side-effect of exposing these meterics is that they will 
immediately provide a "visual face" for Geronimo, over and above the current 
festive rainbow feather.

Network Management System users will be able to immediately
wire up beautiful gauges, meters, pie charts, dancing grids,
and rotating 3-D balls to these exposed metrics... indirectly
helping to promote the server... right alongside the buzzing 
Weblogic/Websphere/JBoss dashboards :-)

PS... The components in the Tomcat 5 server has 
been thoroughly instrumented for remote JMX, but 
it seems that none of the metrics is exposed 
through Geronimo at this time :-(

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message