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:11:50 GMT

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
Twitter: davsclaus, fusenews
Author of Camel in Action:

View raw message