On Thu, Feb 4, 2010 at 17:03, Alasdair Nottingham <[email protected]> wrote: > 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.
How do you actually do that ? > > 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] > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
