On Tue, Oct 18, 2011 at 9:08 AM, Christian Schneider <ch...@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.ib...@gmail.com> >> wrote: >>> >>> Hi >>> >>> On Mon, Oct 17, 2011 at 3:03 PM, Christian Schneider >>> <cschneider...@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: cib...@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: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/
