Details
-
Type: New Feature
-
Status: Closed
-
Priority: Major
-
Resolution: Fixed
-
Affects Version/s: 1.0-beta-3
-
Fix Version/s: 1.0-beta-4
-
Component/s: jmx
-
Labels:None
-
Number of attachments :
Description
JMX registration is currently handled by a MBeanComponentAdapter.
A better approach would be to deprecate this class and implement a JMXVisitor that can traverse a tree of containers and register them in the JMX registry.
The JMXVisitor would need to be previously configured with information about what components to register in JMX. Several strategies are possible:
1) Manual configuration.
- Instantiate a JMXVisitor and call API methods on it. Something like:
jmxVisitor.registerMbeanInfo(componentPath, mbeanInfo)
This low level API would be used by the other approaces.
2) Groovy markup
When encountering jmx() nodes, call the appropriate registerMbeanInfo methods on a jmxVisitor. At the end of the parsing of the Groovy markup, the visitor is configured. The last step would be to have it traverse the tree.
3) 1.5 Annotations
JMX info could be encoded in annotations. A subclass of JMXVisitor (say AnnotationJMXVisitor) could look for annotations on components while traversing the pico tree.
Using an approach like this would allow people to choose the approach they prefer: Groovy or Annotations. The Groovy jmx() nodes should be designed to be similar to the @jmx annotations.
A similar approach could be used for nano-remoting.
Activity
Field | Original Value | New Value |
---|---|---|
Comment | [ 25453 ] |
Assignee | Michael Ward [ mward ] |
Fix Version/s | 1.0-beta-4 [ 11361 ] | |
Fix Version/s | 1.0-beta-3 [ 11242 ] |
Resolution | Fixed [ 1 ] | |
Status | Open [ 1 ] | Closed [ 6 ] |
A fourth option:
4) ComponentAdapter
JMXVisitor jv = new JMXVisitor();
pico.registerComponent(new JMXCA(caDelegate, jv));
the JMXCA would call jv.register.