Hi Alasdair In my opinion exposing JMXAgent by factory is really breaking the modularization of JMX bundle. JMX bundle shouldn't be treated as a library. We can expose JMXAgent as service and use ServiceFactory but I don't see big useability of that as well. I would like to see other people opinions. What do you think?
Cheers, Adam On Thu, Feb 4, 2010 at 10:38 AM, Alasdair Nottingham <[email protected]> wrote: > Hi Adam, > > In response to your first email I do not think we should force the use > of the whiteboard pattern. While it is a good pattern in a lot of > situations it doesn't necessarily cover all basis. In my view JMX is > one of those. As I said initially forcing the whiteboard pattern > requires me to expose externals (my MBean server) which I want to keep > private. > > The methods you propose exposing in the JMXAgent were exactly the > methods I was thinking of last night. They would allow me to do > everything I need to do. > > In order to help me with my second requirement (to be able to have one > installation of a bundle manage multiple OSGi frameworks) I am > proposing the following: > > public interface JMXAgentFactory > { > public JMXAgent createAgent(BundleContext ctx); > } > > this would be registered as a service in the registry. Lifecycle and > MBean registration would then be managed by the caller by calling the > relevant JMXAgent methods. > > What do you think? > Alasdair > > On 4 February 2010 10:21, adam wojtuniak <[email protected]> wrote: > > 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] > >>> > >> > >> > > > > > > -- > Alasdair Nottingham > [email protected] >
