camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: [Discuss] How to do JMX in Apache Camel?
Date Tue, 18 Oct 2011 07:08:24 GMT
It would be great to be able to use both but I think that will not work.
The MBeanAssembler only reads the annotations if the object is not 
already an MBean or MXBean. So
if there is an interface then the annotations do not work anymore.

Sio we have to decide for one way to do this. Of course the annoations 
have some advantages like a little less code and they allow to have 
documentation
for the attributes and operations but I think the advantage is small. So 
I would rather simply create MXBean interfaces for all our MBeans and 
remove all the JMX annotation support code from camel.

Christian

Am 18.10.2011 08:42, schrieb Claus Ibsen:
> 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.ibsen@gmail.com>  wrote:
>> Hi
>>
>> On Mon, Oct 17, 2011 at 3:03 PM, Christian Schneider
>> <cschneider111@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: cibsen@fusesource.com
>> Web: http://fusesource.com
>> Twitter: davsclaus, fusenews
>> Blog: http://davsclaus.blogspot.com/
>> Author of Camel in Action: http://www.manning.com/ibsen/
>>
>
>


-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com


Mime
View raw message