Hi There is a JIRA ticket from the community about adding interfaces for the various MBean we have in camel-core https://issues.apache.org/jira/browse/CAMEL-4468
I assume those interface would transpose to the MXBeans beans you refer to? That would be a good idea to have both the interfaces and the @Managed annotations, the interfaces makes it easier for community end users who want as a client to access Camel JMX details. And this is easier to do with a proxy from a interface. On Tue, Oct 18, 2011 at 8:11 AM, Claus Ibsen <claus.ib...@gmail.com> wrote: > Hi > > On Mon, Oct 17, 2011 at 3:03 PM, Christian Schneider > <cschneider...@googlemail.com> wrote: >> Hi all, >> >> I recently had to dive quite deep into the Camel JMX annotations and their >> implementation. In fact much deeper then I had wanted :-) >> The problem was that I needed to find a way to send notifications from an >> MBean. >> > > When you refer to Camel JMX annotations implementation, you mean the > @ManagedResource that > allows us to easily register and enlist custom components in a > consistent and uniform may in JMX, so > end users can plugin their custom components (and for the matter beans > / processors, etc) in the Camel JMX tree. > And all together looks like a coherent JMX tree. > > >> There are two very different implementation right now: >> 1) The old way: Using spring JMX annotations and the spring libs >> 2) The new way in camel 2.9+ : Using the new Camel JMX annotations and the >> camel MBeanAssembler >> >> The spring implementations had a quite solid implementation but they made >> camel dependent on the spring libs. So Claus created camel annotations that >> look like the spring ones and implemented the basic functionality. The JMX >> Notification support was not yet implemented so I added it for 2.9 but I am >> not sure if it is a good way to do this in camel at all. >> > > Well that seems like a good addition as Spring JMX annotation have support > for notifications as well. However it was a bit dodgy to get working. > Also it was not need and has not been requested by people so far, and thus > we have not added support for that in the past. > > >> The problem here is that our implementation is not as complete as the spring >> one and I am not sure if it is a good idea to do a generic JMX support lib >> in camel. After all camel is not about JMX in it´s core. In my backport to >> 2.8.2 I had to use the original Java JMX (MXBeans) to avoid adding a spring >> dependency. When doing the code I saw that it is some more work than with >> annotations but not really much. >> > > Camel is all about end users being able to manage Camel at runtime. In > Java JMX is the dominated standard > and is available in all the JDKs. There is no need to add extra JARs > and the APIs is stable etc > (although the APIs could have been more friendlier to use). > And there is a lot of tooling that integrate and works with JMX. > > Many other projects offer JMX management capabilities out of the box > such as ActiveMQ, SMX, Karaf (I assume CXF), > Spring Integration (for that matter) etc. > > > >> So I see two good ways to continue with JMX in camel.. >> 1) Simply go the standard java way (Using e.g. MXBeans). Like said it is a >> bit more work but it is the Java way so everyone who knows JMX will >> understand what we do >> > > The current way is also standard. The MBeanAssembler is just a way of > detecting the annotations and use the annotations > as a meta-data when the ModelMBean is assembler with the details. > > This allows us to very easily expose a Camel component for JMX (it > will by default) but all you have to do in case you want an > additional operation is to annotate that with @ManagedOperation, as > well as mark the class with @ManagedResource. > > In fact this is so similar as Spring does it, that even the > annotations have the same name in Camel and Spring. > > > > >> 2) Create a separate project for the JMX support in apache commons. So other >> projects can benefit from it and there is a chance to make this really good >> > > So far in Apache there has been no motivation for doing so. There is > so many Apache projects that uses and support JMX, > so if there has been a die hard desire to do so. I would assume it was > already done. > > In fact we tried in the past with the commons-management JAR, but that > never took off. It was only Camel who fully adopted it. > Now from Camel 2.9 onwards we removed that JAR and added the few > missing pieces of code directly into Camel itself. > > >> Honestly I would prefer 1) for it´s simplicity and as it lowers the >> complexity of camel by using one less framework. >> >> Christian >> >> -- >> Christian Schneider >> http://www.liquid-reality.de >> >> Open Source Architect >> Talend Application Integration Division http://www.talend.com >> >> > > > > -- > Claus Ibsen > ----------------- > FuseSource > Email: cib...@fusesource.com > Web: http://fusesource.com > Twitter: davsclaus, fusenews > Blog: http://davsclaus.blogspot.com/ > Author of Camel in Action: http://www.manning.com/ibsen/ > -- Claus Ibsen ----------------- FuseSource Email: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/
