ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <cziege...@apache.org>
Subject Re: The Management Agent...
Date Thu, 22 Mar 2012 08:34:32 GMT
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 different bundles,
it is more convenient to have it packaged in a single, self-contained bundle. That is exactly
what the ace-managementagent project supplies.
>
> Finally, we can go even further and provide a Java executable that contains both an OSGi
framework and embedded management agent. This is the ace-launcher 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 not interfere with them). Within our launcher and the single
bundle, we could simply not export anything that is contained within. At first, that sounds
like a tempting solution, but it also means it becomes impossible to communicate 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 resource processors,
won't be able to actually use those resource processors since they need to be able to interact
with Deployment Admin.
>
> Especially the second drawback is not acceptable (we could find a way around the first,
possibly by using getAllServiceReferences() and some reflection).
>
> On the other hand, we don't want to expose all these packages and services to everybody.
>
> The proposed solution, which was previously discussed on the Amdatu website (an open
source project that uses Apache ACE and ran into these same issues) and summarized on there
[1].
>
> The solution involves using mandatory attributes on the imports and exports 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 seeing these packages and getting wired to them
accidentally. Resource processors 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. Especially, can you think of an even better solution?
>
> Greetings, Marcel
>
> [1] http://www.amdatu.org/confluence/display/Amdatu/AMA+issues+in+combination+with+resource+processors



-- 
Carsten Ziegeler
cziegeler@apache.org

Mime
View raw message