Mailing-List: contact aries-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: aries-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of alasdair.nottingham@gmail.com
 designates 74.125.92.148 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=c6QmD2g376OCVl9SJmYNd5ZJ0xFykYw5z7fmqe6zSqKzq4hnzFiavVKZu7m5NuF2Vr
         LHxPKi2tyC8d2dfxhUOl0MgRY/ahm1dYoIqRs99imnnjR+3BgzHCqyqADEtYdXRHlJBo
         HvCTpAva6aUf5eKjBJZPkrrA8m2cZW8c2AtLs=
MIME-Version: 1.0
In-Reply-To: <b23ecedc0910221311q251eb65fra2578c2ffadee410@mail.gmail.com>
References: <340194375.1256159339522.JavaMail.jira@brutus>
	 <c799186f0910221258n26c5b2e6v4db86f302dcc8f8d@mail.gmail.com>
	 <b23ecedc0910221311q251eb65fra2578c2ffadee410@mail.gmail.com>
Date: Sun, 25 Oct 2009 18:56:04 +0000
Message-ID: <c799186f0910251156g533e84ag9e7ed1a3b19b895b@mail.gmail.com>
Subject: Re: [jira] Created: (ARIES-29) Implement JMX Agent
From: Alasdair Nottingham <alasdair.nottingham@gmail.com>
To: aries-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

The problem I have here is that it is not clear to me how this really
helps with the goal of making the components "easily consumed". My
understanding of the JIRA is that it will track MBeans registered in
the service registry and when it sees one it will register it with any
MBeanServers registered in the service registry. So to "consume" the
JMX Mbeans using the agent I need to create an MBeanServer and
register it in the service registry, and then create the MBeans and
also register them in the service registry. As a consumer I could just
as easily construct the MBeans myself and register them without going
via the service registry.

I'm just not sure what the goal of creating this JMX Agent is. Reading
the JIRA I wonder if it has been raised mainly because the RI does
something similar.

Alasdair

2009/10/22 Guillaume Nodet <gnodet@gmail.com>:
> I think when such a problem arise, we need to do the following:
> =A0* provide a default and simple implementation
> =A0* make sure the implementation is easily pluggable so that aries
> consumers can easily replace the part with something more stuitable
> for their runtime
> I think the first point is important in order for basic users to be
> able to use aries components easily, have them deployed in an osgi
> runtime without requiring additional coding. =A0This will help
> attracting more people and grow the users community (and hopefully
> then, the developers community). =A0If we don't provide components that
> can be used directly, people will just go away.
> The second point is necessary to fullfil the requirements you
> expressed: i.e. when you embed an aries component into a given
> runtime, you may need a tighter integration with the runtime, hence
> the need for pluggable parts to replace.
>
> In our case, a simple solution would be to have a simple module that
> will grab or create a default platform mbean server and register it in
> osgi. =A0We could leave out creating a remote jmx connector and all, as
> this would soon have ties to the security bits and such ...
>
> On Thu, Oct 22, 2009 at 21:58, Alasdair Nottingham
> <alasdair.nottingham@gmail.com> wrote:
>> Hi,
>>
>> The JMX specification (taken from the March early draft) says the
>> following about the MBean server:
>>
>> "The construction, maintenance and lifecycle of the MBeanServer which
>> will host the MBeans defined in this specification is intentionally
>> left undefined. It is left undefined as the MBeanServer is invariably
>> tied to the particular application that is responsible for it. For
>> example, the MBeanServer may exist outside the OSGi framework that the
>> MBeans are managing. Or there may be multiple MBean servers which
>> contain the MBeans defined in this specification. The introduction of
>> nested frameworks, such as those defined in RFC 138, may have their
>> management MBeans hosted in the MBeanServer which hosts the MBeans for
>> the outermost OSGi container. Alternatively, these MBeans may be
>> hosted, for example, in an application server's MBeanServer which is
>> embedding mulitple OSGi containers."
>>
>> My interpretation of this is that the specification does not describe
>> how the MBeans are registered with an MBean server. So this JIRA seems
>> to go beyond what is required to implement the JMX specification.
>>
>> This is not necessarily a problem, but it does make me wonder if doing
>> this work is in the scope of the original incubator proposal. I think
>> registration of MBeans with an MBeanServer is the responsibility of
>> the runtime into which Aries has been embedded rather than the aries
>> podling itself.
>>
>> What do people think?
>> Alasdair
>>
>> 2009/10/21 Adam Wojtuniak (JIRA) <jira@apache.org>:
>>> Implement JMX Agent
>>> -------------------
>>>
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Key: ARIES-29
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 URL: https://issues.apache.org/jira/bro=
wse/ARIES-29
>>> =A0 =A0 =A0 =A0 =A0 =A0 Project: Aries
>>> =A0 =A0 =A0 =A0 =A0Issue Type: New Feature
>>> =A0 =A0 =A0 =A0 =A0Components: JMX
>>> =A0 =A0Affects Versions: 1.0
>>> =A0 =A0 =A0 =A0 =A0 =A0Reporter: Adam Wojtuniak
>>> =A0 =A0 =A0 =A0 =A0 =A0 Fix For: 1.0
>>>
>>>
>>> Implement JMX Agent. It should be responsible for tracking all MBean se=
rvers(registered as a services) and services which will be exposed as a Man=
aged Beans (MBeans).
>>> JMX Agent should register following MBeans: Framework MBean, Bundle Sta=
te MBean, Service State MBean, Package State MBean, Permission Admin MBean,=
 Configuration Admin MBean,
>>> Provisioning Service MBean, User Admin MBean, Conditional Permission Ad=
min MBean.
>>> It is open issue if we should track MBean servers registered as service=
s but for now we can follow RI of JMX which listen to MBean Server services=
.
>>> For now we can track MBeanServers and when service is discovered regist=
er MBeans. Same in case when service is exposed as Managed MBeans it should=
 be registered (on all available MBean servers) when is discovered.
>>>
>>> --
>>> This message is automatically generated by JIRA.
>>> -
>>> You can reply to this email to add a comment to the issue online.
>>>
>>>
>>
>>
>>
>> --
>> Alasdair Nottingham
>> alasdair.nottingham@gmail.com
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>


--=20
Alasdair Nottingham
alasdair.nottingham@gmail.com