Hi Christian On Tue, Oct 18, 2011 at 8:42 AM, Claus Ibsen <claus.ib...@gmail.com> wrote: > 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 Object jmx_proxy = 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. > 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´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: 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/ >> > > > > -- > 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/ > -- 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/
