Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Received-SPF: pass (nike.apache.org: domain of claus.ibsen@gmail.com
 designates 209.85.215.173 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4EA185BF.4060303@die-schneider.net>
References: <4E9C27AB.60601@die-schneider.net>
 <CAGB5yN=UnyofvoG6_-uXV0_gZem+3iX4nAmJATPPTYXovz=8ug@mail.gmail.com>
 <CAGB5yNmkF16qHoqLTMnYLfALYr=upNEQFQT0UCP2ubETQ9PoMQ@mail.gmail.com>
 <CAGB5yNmNQ==OQMgJ9beXHLRxXWsGYHTedbPmvctYK1LoXpz=4g@mail.gmail.com>
 <4EA185BF.4060303@die-schneider.net>
From: Claus Ibsen <claus.ibsen@gmail.com>
Date: Sun, 23 Oct 2011 10:10:36 +0200
Message-ID: 
 <CAGB5yNkBOuPeRo2QSMFKhoNQDbfV3F0d3Z9SYAvYi5pWo34Xtw@mail.gmail.com>
Subject: Re: [Discuss] How to do JMX in Apache Camel?
To: dev@camel.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Fri, Oct 21, 2011 at 4:46 PM, Christian Schneider
<chris@die-schneider.net> wrote:
> Am 21.10.2011 13:28, schrieb Claus Ibsen:
>>
>> Hi Christian
>>
>> On Tue, Oct 18, 2011 at 8:42 AM, Claus Ibsen<claus.ibsen@gmail.com>
>> =A0wrote:
>>>
>>> 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 think it would be valuable if you took at look at CAMEL-4468. You
>> have an keen interrest in API which can help here.
>>
>> Its although API for JMX Clients (eg for Camel end users from a client
>> to access the Camel MBeans using an interface.). CAMEL-4468 makes this
>> easier for clients as the JDK JMX API has a way of proxy using a
>> interface, which makes it much easier for clients to access MBeans.
>>
>> Basically something like this code line
>> =A0 =A0Object jmx_proxy =3D
>> MBeanServerInvocationHandler.newProxyInstance(getMBeanServerConnection()=
,
>> objectName, interfaceClass, notificationBroadcaster);
>>
>> That makes it easier for Camel end users to acces the Camel MBeans.
>>
>>
>> However the other point is how Camel itself registers MBeans in the
>> MBeanServer. This is still using JMX annotations (Camel or Spring JMX
>> annotations). But we can add support for MXBean interfaces as well (eg
>> possible the interfaces from CAMEL-4468).
>> However the benefit of the JMX annotations is that they allow you to
>> add meta data such as description and possible other stuff we can add
>> as well. Also with JMX annotations its sort of a "mix in" approach
>> where Camel can use a ManagedEndpoint as base class and then add those
>> additional JMX annotations for a component. See for example camel-jms
>> in the JmsEndpoint class, how we can easily add special JMX attributes
>> and operators. Using interfaces this becomes as far as I can see, more
>> difficult.
>
> Can you explain how this Mixin aproach is better than an interface?
>

With interfaces you need to implement or extend other interfaces.

The annotations doesn't require this per see. You can just add
annotations to your existing class, and
no need to implement interfaces, etc. Also with annotations you do
keep the code in *one* file,
as well as annotations can have additional meta-data such as the descriptio=
n.


> To do the same for JmsEndpoint =A0that the annotations do you would just =
have
> to let it implement JmsEndpointMXBean and also have the getters and sette=
rs
> for the attributes there.
>

Yeah its compelling but unfortunately JMX forces you to use *MXBean as the =
name,
which essentially forces you to create a special interface for JMX
itself. You may also
have an interface for client users to use. This essentially duplicate
your effort.

With annotations you don't need this. Just add the annotations on the
attribute/operations and you are done.


>
>>
>>
>>
>>
>>> I assume those interface would transpose to the MXBeans beans you refer
>>> to?
>
> Exactly if you create the MXBeans using interfaces named ClasNameMXBean t=
hen
> the JDK knows how to instantiate the MXBean and the user can use this
> interface for proxies.
>

That is the only compelling reason for MXBean interaces as Camel end
users who want
to access the Camel MBeans as a client can use those interfaces
instead of using the cumbersome
generic JMX API.

But *any* interface can do from a client point of view, it does not
need to be named *MXBean.


>>>
>>> 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.
>
> At the moment I have no idea how we could have both in the same bean. So =
we
> have to decide for each bean.
>
> Christian
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
>


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