aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@gmail.com>
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 14:55:28 GMT
What about exporting the package from jmx-core bundle, but not from
jmx-bundle bundle.
This would mean that this factory is an internal thing which fills a
purpose but it's not supposed
to be used in "simple" environments where jmx-bundle would be deployed
?  This would mean
that Alasdair would have to repackage the jmx bundle for its own use.

I suppose another way would be to attach a fragment containing this
factory, right ?

Anyway, I'm not so strong on that personally.  Keeping the bundle
clean is a nice goal, but
accommodating different use cases is equally important.  I honestly
don't think adding this package
is that big a deal at the moment, as it only contains one class with a
very specific purpose.
But maybe a bit of javadoc on the class itself would be nice in all
cases so that our users are well
aware of the specific use of that factory class.

On Thu, Feb 4, 2010 at 15:10, 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
>>
>



-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

Mime
View raw message