Well, you get ALL the goodies of DS's dependency handling, you can still depend on other services and you get the properties. Seems like powerful goodies to me over a Bundle Activator ...
You could try subclassing and get the configuration parameters in a static method you call from the subclass constructor. @Component(provide=ConstructorClass.class) public Comp extends ConstructorClass { public Comp() { super( getParms() ); } static Whatever getParms() { BundleContext c = FrameworkUtil.getBundle(Comp.class).getBundleContext(); ... } } And if that does not work, delegation is your friend ... I think I would go for immediate with DS and depend on the Config Admin (or better use its properties). Kind regards, Peter Kriens On 11 jan 2011, at 19:38, David Jencks wrote: > > 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 >>>>> >>>> >>>> -- >>>> fmesc...@adobe.com >>>> +41 61 226 98 44 >>>> >>> >> >