On Jan 10, 2011, at 3:41 PM, Felix Meschberger wrote: > Hi, > > Am Montag, den 10.01.2011, 23:31 +0000 schrieb David Jencks: >> Based on studying the DS spec and FELIX-2563 I think the answer is "yes" but >> I'd like to double check. > > Yes, a component is a single class, which is also used as the service if > it declares one or more Service elements. > >> >> I want to have a factory class as my DS Component that creates a single >> framework-wide instance of the service that will get registered (configured >> from the properties the component gets). I don't want the factory component >> class to implement any of the service interfaces. Is there any way to do >> this? > > If you declare your component to be delayed (the default for components > to be registered as services), there is internally a factory (a > ServiceFactory actually) which creates a single instance of the > component as soon as the first client is requesting it, that is > accessing the service. > > This is much like a ServiceFactory where each bundle actually gets the > same instance instead of a different instance for each bundle. > > Now, what exactly should that factory you envision have to do ?
I have a bunch of classes designed to have all the configuration parameters supplied in the constructor and set as final fields. Once the configuration parameters have been set, they can't be changed (the object will stop working). Since this will be used in non-osgi contexts, making the fields non-final is not plausible. I've written a component that takes the properties from config admin, parses them into the constructor parameters, and creates the object. I'd like DS to be able to register the object I've created as the service, rather than registering the component as the service. Apparently this is not possible with DS, so my workaround is to have my component delegate to my service object. My view is that requiring the code that converts between the config-admin supplied properties and whatever configuration method a well designed object might use be in the actual object is a serious separation of concerns issue. thanks david jencks > > Should it only create the component, once configuration is available ? > This can easily be achieved by the configuration-policy=required on the > Component element. And this is still handled by DS. > >> >> The workaround I've found is to have the component delegate to the service >> implementation class instance and implement all the desired service >> interfaces. This seems less than ideal. >> >> thanks >> david jencks >> > > -- > fmesc...@adobe.com > +41 61 226 98 44 >
