Hello Simon,
Thanks for the reply. This is a subject I would truly enjoy discussing. I do
have the book, it is excellent.
I'll elaborate on the problem domain and how I'm approaching.
We have an existing framework that I'm converting to OSGI. This framework
is used to create integration components that we run throughout our
enterprise. We call these components Adapters, they have an input channel
an output channel and a processor. The processor can have 0..* processes
and processes can have 0..* rules. Each instance of an Adapter is defined
externally and is pulled in at launch time to construct and inject
dependencies. Once we have injected all of the dependencies we start the
Adapter and it does work.
I've been working on how to implement this in OSGI and trying to minimize
the coupling to OSGI APIs (as much as reasonably possible). This desire
makes DS very attractive.
Approaches taken:
1. Use DS Component Factories
This was my first approach and I abandoned it because I felt the amount of
code needed was too much. Each component that I wanted to be able to create
instances of needed another configurator class to be injected with the
ComponentFactory for creating the component instances. If the number of
components was small and static I would probably have stayed with this
approach. It is very manageable because of it's synchronous nature. Our
framework has hundreds of components that could be included in an Adapter
configuration and we are always adding new components as the need arises.
So, my feeling at the time was that this approach would be too burdensome.
There may be ways to generalize this so that one configurator class could be
used for all ComponentFactories but I have not pursued this. This may be
something to reconsider.
2. Use ConfigurationAdmin and DS
This is the approach I'm currently working on and it requires very little
code but does present some challenges. Each component that I want to be
able to create an instance of has a DS component definition. In this
definition I set the configuration policy to required. I have one bundle
that is responsible for configuration management. When it starts it reads
in the configuration file(s) from a URL(s). The structure of the file (see
below) defines components, their properties and dependencies. The xml is
turned into an object model and special properties are set (guid and
parent.guid) that allows .target properties to be set with filters in parent
components (to allow dependencies to be resolved/injected). Once the object
model is constructed it represents a set of components and properties to be
constructed using ConfigurationAdmin. ConfigurationAdmin is used to
construct new Configuration instances via createFactoryConfiguration(...)
and the properties are passed by calling configuration.update(properties).
Then DS does the work of creating new components and injecting the
dependencies (or is this SCR?). This seems to work very nicely but the
asynchronous nature of configuration.update(properties) presents a challenge
of knowing when the Adapter can be started.
To manage when the Adapter can be started I added behavior to parent
components that have 0..n children. This behavior receives a set of guids
(from it's component properties) that that are the guids of the children it
is to be injected with. When children are added/removed from a parent a
check is made to see if all of the expected guids are available. If true
then the parent component declares that it is in a ready state. Once the
entire dependency chain is in a ready state the Adapter can be started. If
the dependency chain ever leaves the ready state the adapter is stopped.
Another challenge is relaunching the platform without the -clean option. If
the framework was always launched with the -clean option there wouldn't be
any issues with reading the configuration and creating components. If the
-clean option is not used and we blindly read the configuration and create
components we are going to end up with duplicates. So to address this I've
been working on synchronization behavior (starting to sound crazy?).
That is where I'm at right now. I have not explored the enable/disable
functionality you mentioned.
I would greatly appreciate any feedback/advice that you have. I'm wondering
(after having written this email) if a blend of these two approaches would
be better. Especially if the configurator (using component factories in
approach 1) could be generalized. I'm also wondering if I've gone off the
deep end on this and if there are easier solutions readily available that
I'm not aware of.
Thank you very much.
Tom
PS: here is the xml configuration file.
<configuration>
<component>
<factory>[DS component name]</factory>
<properties>
<property name="[name]" value="[value]"/>
</properties>
<!-- a child component. (ie: a dependency for the parent) -->
<component>
<factory>[DS component name]</factory>
<type>[name of parent's referenced service. used to set the .target
within parent]</type>
<properties>
<property name="[name]" value="[value]"/>
</properties>
</component>
</component>
</configuration>
On Wed, Jun 9, 2010 at 11:04 AM, Simon J Archer <[email protected]> wrote:
>
> Hello Tom
>
> Maybe you can tell us more about what you're doing and how you're doing it.
> One of the benefits of DS is that it simplifies the registration of OSGi
> services, but at the cost of losing some of the control over exactly when a
> service is registered. If you're attempting to only register a (parent)
> service when it has acquired all of its services, you might be better off
> registering, and unregistering, the parent service "by hand" using the OSGi
> APIs rather than using DS. You can do this easily from the DS component's
> activate/deactivate methods.
>
> Other thoughts:
> - Are you using DS Factory Components to dynamically create DS components?
> - Would creating multiple DS component that are enabled/disabled at runtime
> be helpful to your problem?
>
> If you can tell me more I might be able to provide you with further
> recommendations. Also, DS is well covered in the following OSGi book (of
> which I am one of the 3 authors):
> *http://equinoxosgi.org/* <http://equinoxosgi.org/>
>
> Good luck,
>
> Simon
>
>
> From: Tom Kesling <[email protected]> To:
> OSGi Developer Mail List <[email protected]>
> Date: 05/26/2010 02:55 PM Subject: [osgi-dev] ConfigurationAdmin question Sent
> by: [email protected]
> ------------------------------
>
>
>
> Hello,
> I'm using configurationadmin and ds to create service instances and
> I'm trying to understand how to know when all of the instances have
> been created.
>
> There are parent to child relationships where a parent can have 0..n
> children.
> I don't want to start using a parent until all of it's children have
> been created.
>
> Does anyone have any advice on how to manage/approach this?
>
>
> Thanks,
> T
> _______________________________________________
> OSGi Developer Mail List
> [email protected]
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
>
> _______________________________________________
> OSGi Developer Mail List
> [email protected]
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
