I wonder if you could not better do the whole thing as a DS component? Just
create a class for each configuration and use DS to manage its dependencies.
This configuration class could then register a service when it is fully
initialized. This model maps very well to DS's lifecycle handling and is very
robust.
Imho it is better to use services to model these kind of runtime dependencies
instead of doing things synchronously and trying to find the right
initialization order.
Kind regards,
Peter Kriens
On 10 jun 2010, at 15:10, Tom Kesling wrote:
> 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
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
