Mailing-List: contact dev-help@ace.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ace.apache.org
MIME-Version: 1.0
In-Reply-To: <7ED79ED9-CE56-4949-ADD1-091C17F6078F@luminis.nl>
References: <7ED79ED9-CE56-4949-ADD1-091C17F6078F@luminis.nl>
Date: Thu, 22 Mar 2012 09:34:32 +0100
Message-ID: 
 <CAKkCf4oGoeUdS+PU6W61OcxwUE+Jb5sREE8RokRDN_nUCvwueA@mail.gmail.com>
Subject: Re: The Management Agent...
From: Carsten Ziegeler <cziegeler@apache.org>
To: dev@ace.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,

I don't have that much experience in this area, but on a first look
the suggested solution looks good to me. We can give it a spin and see
how it turns out.

Carsten

2012/3/20 Marcel Offermans <marcel.offermans@luminis.nl>:
> Within ACE, we have a management agent that is very flexible and modular,=
 which is nice because it allows you to customize it any way you want. The =
ace-target-devgateway project supplies such a modular agent and can be used=
 during development.
>
> On the other hand, once you've composed a management agent out of differe=
nt bundles, it is more convenient to have it packaged in a single, self-con=
tained bundle. That is exactly what the ace-managementagent project supplie=
s.
>
> Finally, we can go even further and provide a Java executable that contai=
ns both an OSGi framework and embedded management agent. This is the ace-la=
uncher project.
>
> With this management agent, we have created an OSGi framework that can be=
 updated dynamically. The management agent itself, although present, should=
 probably be hidden from the other bundles that are installed (so they do n=
ot interfere with them). Within our launcher and the single bundle, we coul=
d simply not export anything that is contained within. At first, that sound=
s like a tempting solution, but it also means it becomes impossible to comm=
unicate with this agent, which has two important drawbacks:
>
> 1) There are a few configurable aspects in the management agent that use =
Configuration Admin so they can be dynamically reconfigured at runtime. If =
you cannot access this service, you cannot (re)configure anything.
>
> 2) The Deployment Admin specification, which can be extended by using res=
ource processors, won't be able to actually use those resource processors s=
ince they need to be able to interact with Deployment Admin.
>
> Especially the second drawback is not acceptable (we could find a way aro=
und the first, possibly by using getAllServiceReferences() and some reflect=
ion).
>
> On the other hand, we don't want to expose all these packages and service=
s to everybody.
>
> The proposed solution, which was previously discussed on the Amdatu websi=
te (an open source project that uses Apache ACE and ran into these same iss=
ues) and summarized on there [1].
>
> The solution involves using mandatory attributes on the imports and expor=
ts that are part of the management agent to create a "name space" for every=
 bundle that is part of it. These attributes prevent other bundles from see=
ing these packages and getting wired to them accidentally. Resource process=
ors can use these attributes to explicitly bind to the right packages.
>
> I propose to start using these attributes in ACE. Because we use the Auto=
 Configuration resource processor from Felix, we probably need to repackage=
 it so it supports these attributes. I would like your feedback on this. Es=
pecially, can you think of an even better solution?
>
> Greetings, Marcel
>
> [1] http://www.amdatu.org/confluence/display/Amdatu/AMA+issues+in+combina=
tion+with+resource+processors


--=20
Carsten Ziegeler
cziegeler@apache.org