camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <claus.ib...@gmail.com>
Subject Re: [Discuss] How to do JMX in Apache Camel?
Date Tue, 18 Oct 2011 07:35:07 GMT
On Tue, Oct 18, 2011 at 9:08 AM, Christian Schneider
<chris@die-schneider.net> wrote:
> 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.
>

The MBean assembler can detect if there is annotations and leverage
those. If not it can fallback and use the interface.
So its of course possible to have both.

> 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.
>

-1

End users of Camel can easily add custom operations / attributes of
their components to Camel by using the annotations.
This has been the way people have been doing this since Camel 1.x was
created (using Spring Annotations).



> 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愀 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愀 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
>
>



-- 
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/

Mime
View raw message