ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Offermans <marcel.offerm...@luminis.nl>
Subject The Management Agent...
Date Tue, 20 Mar 2012 19:43:35 GMT
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
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message