I forgot that we already have two methods in JMXAgent: *void* registerMBeans(*final* MBeanServer server);
*void* unregisterMBeans(*final* MBeanServer server); It will be much safer to expose those two methods and let the user register MBeans with his server. Cheers, Adam On Thu, Feb 4, 2010 at 10:03 AM, adam wojtuniak <[email protected]>wrote: > Hi Alasdair > > One solution is to register JMX agent as a service and provide method for > adding and removing external MBeanServer > to the agent servers list. That will solve problem 1. But Iam not sure if > that is good pattern in OSGI since we are using > whiteboard pattern for MBean servers. > > Regards, > Adam > > > > On Wed, Feb 3, 2010 at 10:00 PM, Alasdair Nottingham <[email protected]>wrote: > >> Hi, >> >> Back when ARIES-29 was originally raised I expressed a concern about >> the aries agent working the way it does. However I always wanted a >> more flexable approach so we can reuse the MBeans with a different >> agent. >> >> Stepping back for a sec here are my requirements: >> >> 1. I have an MBeanServer that is mine, it is not public and I do not >> want to put it in the service registry to be used by others. >> 2. I would like to have two separate OSGi frameworks running at once >> in a JVM, but without needing to install the bundle into each >> framework. >> 3. I want to control whether MBeans are registered for compendium >> services. >> 4. I have an MBeanServer that federates multiple MBeanServers >> together. I wish to register the MBean with additional properties to >> allow me to select between the multiple Mbeans that will be available. >> >> As far as I can tell none of these is possible. I like Tim's >> suggestion because I can be in total control of how the management >> agent works and implement 1-4, but still reuse the MBean >> implementations in aries. However looking at the code I think there is >> an possible alternative which I thought I would throw out there. If >> the JMXAgent was available in the service registry I should be able to >> do requirements 1, 3 and 4. However since I want to get 2 in as well I >> think we could have a factory to create JMXAgent instances. >> >> What do you think? >> Alasdair >> >> On 3 February 2010 18:43, adam wojtuniak <[email protected]> wrote: >> > Hi Tim >> > >> > Iam against exposing MBeans outside JMX bundle. >> > Lifecycle of all MBeans is managed by JMX bundle using MBeanHandlers and >> I >> > think it should be this way. >> > In your factory you are using framework MBeans but what will happen if >> you >> > want to use >> > compendium MBeans. They all created based on availability of compendium >> > services which is managed >> > inside JMX bundle. In such a case the outside user will have to manage >> those >> > MBeans >> > by himslef. Even he can't be sure if could get MBean from JMX could be >> not >> > available at the time. >> > Currently the best way to register MBeans in an external MBean server is >> to >> > register the server as a >> > service. >> > >> > Regards, >> > Adam Wojtuniak >> > >> > On Wed, Feb 3, 2010 at 4:21 PM, Tim Mitchell (JIRA) <[email protected]> >> wrote: >> > >> >> Add a factory class to allow the OSGi JMX MBeans to be registered in an >> >> external MBean server >> >> >> >> >> --------------------------------------------------------------------------------------------- >> >> >> >> Key: ARIES-141 >> >> URL: https://issues.apache.org/jira/browse/ARIES-141 >> >> Project: Aries >> >> Issue Type: Improvement >> >> Components: JMX >> >> Reporter: Tim Mitchell >> >> Priority: Minor >> >> Attachments: JMXFactoryPatch.txt >> >> >> >> Currently there is no way of accessing the Apache Aries MBeans in order >> to >> >> register them in an external MBean server. I am proposing a factory >> class >> >> that will be exported from the jmx bundle that will allow users to >> access >> >> the internal MBean. >> >> I have supplied a patch with my suggested class. >> >> >> >> -- >> >> This message is automatically generated by JIRA. >> >> - >> >> You can reply to this email to add a comment to the issue online. >> >> >> >> >> > >> >> >> >> -- >> Alasdair Nottingham >> [email protected] >> > >
