Hey Peter, I appreciate the response. It makes good sense. Thank you. Cheers, T
On Mon, Jun 14, 2010 at 5:17 AM, Peter Kriens <[email protected]> wrote: > 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 > _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
