camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <>
Subject Re: [Discuss] How to do JMX in Apache Camel?
Date Tue, 18 Oct 2011 06:42:15 GMT

There is a JIRA ticket from the community about adding interfaces for
the various MBean we have in camel-core

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
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 <> wrote:
> Hi
> On Mon, Oct 17, 2011 at 3:03 PM, Christian Schneider
> <> 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
>> Open Source Architect
>> Talend Application Integration Division
> --
> Claus Ibsen
> -----------------
> FuseSource
> Email:
> Web:
> Twitter: davsclaus, fusenews
> Blog:
> Author of Camel in Action:

Claus Ibsen
Twitter: davsclaus, fusenews
Author of Camel in Action:

View raw message