It looks like we are making progress on requirements 1, 3 and 4. It is just requirement 2 that is left behind. Just to recap requirement 2 is:
2. I have multiple separate OSGi frameworks running at once in a JVM, but I would like to only have the JMX bundle installed once, to reduce runtime footprint. The JMXAgent is, quite reasonably, only aware of a single framework at a time. Which is where I got to with my multiple JMXAgents idea. I do not really understand why it would break the JMX modularity, I thought it was a better modularity solution than Tim's original suggestion. While I could follow Guillaume's suggestion of using a fragment I think this really breaks modularity and I would prefer to have a solution that does not push me down this route. On the point about using OSGi security to protect an MBeanServer I really do not think it is a good solution for two reasons: 1. My MBeanServer is part of my bundles internals so registering it in the service registry breaks the modularity of my system. 2. It only works if Java 2 security is enabled, which is often disabled for performance reasons. Do you have any suggestions on how we can get a solution to option 2? Thanks Alasdair On 4 February 2010 14:29, adam wojtuniak <[email protected]> wrote: > There is also one solution for keeping your MBean server private. You can > use ServicePermission for > your MBeanServer and grant that permission only to JMX bundle. That will be > more OSGi way. > > Regards, > Adam > > On Thu, Feb 4, 2010 at 2:10 PM, adam wojtuniak <[email protected]>wrote: > >> 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] >>> >> >> > -- Alasdair Nottingham [email protected]
