There should be a component category in JIRA for camel-jmx As for this issue, I have some code that's mostly working. I'll be putting the finishing touches on over the course of the next couple of weeks as time permits. Any input on the feature is appreciated.
On Wed, Nov 10, 2010 at 11:47 AM, Mark Ford (JIRA) <j...@apache.org> wrote: > camel-jmx: Auto creation of a monitor bean via endpoint properties > ------------------------------------------------------------------ > > Key: CAMEL-3325 > URL: https://issues.apache.org/activemq/browse/CAMEL-3325 > Project: Apache Camel > Issue Type: New Feature > Reporter: Mark Ford > Priority: Minor > > > The current version of the camel-jmx component allows for the forwarding of > JMX notifications from an mbean into the route. In addition to receiving > notifications, a user may want to monitor an mbean. The consumer currently > doesn't have any special handling for monitor beans. The user would need to > write a few lines of Java code to create their monitor and deploy it. Once > deployed, the monitor bean could use the objectName for the monitor bean in > conjunction with the camel-jmx component to forward events into the route. > > For example: > > {code:java} > CounterMonitor monitor = new CounterMonitor(); > monitor.addObservedObject(makeObjectName("simpleBean")); > monitor.setObservedAttribute("MonitorNumber"); > monitor.setNotify(true); > monitor.setInitThreshold(1); > monitor.setGranularityPeriod(500); > registerBean(monitor, makeObjectName("counter")); > monitor.start(); > {code} > > The proposed new feature is to add a new type of consumer that automatically > creates and registers a monitor bean for the specified objectName and > attribute. Additional endpoint attributes would be added to allow the user to > specify the attribute to monitor, type of monitor to create, and any other > required properties. The code snippet above could be condensed into a set of > endpoint properties. The consumer would use these properties to create the > CounterMonitor, register it, and then subscribe to its changes. > > For example: > > {code:java} > from("jmx:platform?objectDomain=myDomain&objectName=simpleBean&monitorType=counter&observedAttribute=MonitorNumber&initThreshold=1&granularityPeriod=500").to("mock:sink"); > {code} > > New endpoint attributes: > > ||property||type||applies to||description|| > | monitorType |enum| all | one of counter, guage, string | > | observedAttribute |string| all | the attribute being observed | > | granualityPeriod |long| all | granularity period (in millis) for the > attribute being observed. As per JMX, default is 10 seconds | > | initThreshold |number| counter | initial threshold value | > | offset |number| counter | offset value | > | modulus |number| counter | modulus value | > | differenceMode | boolean | counter, gauge | true if difference should be > reported, false for actual value | > | notifyHigh | boolean | gauge | high notification on/off switch | > | notifyLow | boolean | gauge | low notification on/off switch | > | highThreshold | number | gauge | threshold for reporting high notification | > | lowThreshold | number | gauge | threshold for reporting low notificaton | > | notifyDiffer | boolean | string | true to fire notification when string > differs | > | notifyMatch | boolean | string | true to fire notification when string > matches | > | stringToCompare | string | string | string to compare against the attribute > value | > > Other considerations > * If the mbeanserver is remote, then the JMXRemote library or similar > solution is required to register the monitor bean > * name of the monitor bean should be derived from the observed object > * if the observed bean is unregistered then the route should send some > notification or exception through its route to signal the processors > > > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > >
