aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alasdair Nottingham <...@apache.org>
Subject Re: [jira] Created: (ARIES-141) Add a factory class to allow the OSGi JMX MBeans to be registered in an external MBean server
Date Thu, 04 Feb 2010 16:03:11 GMT
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 <adamwojtuniak@gmail.com> 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 <adamwojtuniak@gmail.com>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 <not@apache.org>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 <adamwojtuniak@gmail.com>
>>> 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 <
>>> adamwojtuniak@gmail.com>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 <not@apache.org
>>> >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 <adamwojtuniak@gmail.com>
>>> 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) <
>>> jira@apache.org>
>>> >>> 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
>>> >>> not@apache.org
>>> >>>
>>> >>
>>> >>
>>> >
>>>
>>>
>>>
>>> --
>>>  Alasdair Nottingham
>>> not@apache.org
>>>
>>
>>
>



-- 
Alasdair Nottingham
not@apache.org

Mime
View raw message