camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Willem Jiang <>
Subject Re: [Discuss] How to do JMX in Apache Camel?
Date Wed, 19 Oct 2011 14:06:05 GMT
On 10/19/11 3:43 PM, Claus Ibsen wrote:
> On Tue, Oct 18, 2011 at 10:41 AM, Christian Schneider
> <>  wrote:
>> Am 18.10.2011 09:35, schrieb Claus Ibsen:
>>> On Tue, Oct 18, 2011 at 9:08 AM, Christian Schneider
>>> <>    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.
>> I tested it. At least right now it does not work.
> Ah I was not clear here. I meant we can *add* support so the assembler
> can fallback
> and use the interface(s) if the JMX annotations was not present.
> Then we have both situations covered.

I'm +1 for using the MBeanAssembler because it's more flexible if you 
has lots object to manage.
If you has 10 beans need to be managed, adding 10 MBean interfaces maybe 
not too much work, but you may forget to add the managed method on the 
interface when you update the bean method.

>>>> 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).
>> Still we can think about changing that for 3.0. I am not saying we must
>> change it.
> Yeah sure Camel 3.0 is more open for changes than 2.x.
> However I would look for very good reasons to be convinced to take
> away something
> that has been included in Camel 1.x (eg for a long time). And which is
> a feature that is
> end user faced. Eg its used by end users to enlist their custom
> components / beans /
> processors etc. in JMX together with the Camel MBeans, so it all is coherent.
>> Christian
>> --
>> Christian Schneider
>> Open Source Architect
>> Talend Application Integration Division

Blog: (English)
Twitter: willemjiang
Weibo: willemjiang

View raw message