On Jan 11, 2011, at 6:40 AM, Peter Kriens wrote: > Why not register your object with the Bundle Context, which you can get from > the Component Context? > > reg = ccontext.getBundleContext().registerService( "<class>", > serviceObject, properties); > > In the deactivate, just unregister this service. It do not think it gets much > easier?
Obviously I can do this, but I think this is simpler in a bundle activator since it eliminates one of the main reasons to use DS, lazy activation based on a need for a service. Am I missing something? thanks david jencks > > Kind regards, > > Peter Kriens > > On 11 jan 2011, at 01:09, David Jencks wrote: > >> >> 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 >>>> >>> >>> -- >>> [email protected] >>> +41 61 226 98 44 >>> >> >
