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.offerm...@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 cziege...@apache.org
