You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by adam wojtuniak <ad...@gmail.com> on 2010/02/03 19:43:06 UTC
Re: [jira] Created: (ARIES-141) Add a factory class to allow the OSGi
JMX MBeans to be registered in an external MBean server
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) <ji...@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.
>
>
Re: [jira] Created: (ARIES-141) Add a factory class to allow the OSGi
JMX MBeans to be registered in an external MBean server
Posted by Guillaume Nodet <gn...@gmail.com>.
On Thu, Feb 4, 2010 at 17:03, Alasdair Nottingham <no...@apache.org> 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 <ad...@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 <ad...@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 <no...@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 <ad...@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 <ad...@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
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [jira] Created: (ARIES-141) Add a factory class to allow the OSGi
JMX MBeans to be registered in an external MBean server
Posted by Alasdair Nottingham <no...@apache.org>.
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 <ad...@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 <ad...@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 <no...@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 <ad...@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 <ad...@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
Re: [jira] Created: (ARIES-141) Add a factory class to allow the OSGi
JMX MBeans to be registered in an external MBean server
Posted by adam wojtuniak <ad...@gmail.com>.
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 <ad...@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 <no...@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 <ad...@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 <ad...@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
>>
>
>
Re: [jira] Created: (ARIES-141) Add a factory class to allow the OSGi
JMX MBeans to be registered in an external MBean server
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <ad...@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 <no...@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 <ad...@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 <ad...@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
Re: [jira] Created: (ARIES-141) Add a factory class to allow the OSGi
JMX MBeans to be registered in an external MBean server
Posted by adam wojtuniak <ad...@gmail.com>.
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 <no...@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 <ad...@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 <ad...@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
>
Re: [jira] Created: (ARIES-141) Add a factory class to allow the OSGi
JMX MBeans to be registered in an external MBean server
Posted by Alasdair Nottingham <no...@apache.org>.
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 <ad...@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 <ad...@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 <no...@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 <ad...@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) <ji...@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
Re: [jira] Created: (ARIES-141) Add a factory class to allow the OSGi
JMX MBeans to be registered in an external MBean server
Posted by adam wojtuniak <ad...@gmail.com>.
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 <ad...@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 <no...@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 <ad...@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) <ji...@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
>>
>
>
Re: [jira] Created: (ARIES-141) Add a factory class to allow the OSGi
JMX MBeans to be registered in an external MBean server
Posted by adam wojtuniak <ad...@gmail.com>.
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 <no...@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 <ad...@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) <ji...@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
>
Re: [jira] Created: (ARIES-141) Add a factory class to allow the OSGi
JMX MBeans to be registered in an external MBean server
Posted by Alasdair Nottingham <no...@apache.org>.
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 <ad...@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) <ji...@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