felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Kriens <peter.kri...@aqute.biz>
Subject Re: Does a DS Component and Service have to be the same class?
Date Thu, 13 Jan 2011 17:52:34 GMT
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
>>>>> 
>>>> 
>>>> -- 
>>>> fmeschbe@adobe.com
>>>> +41 61 226 98 44
>>>> 
>>> 
>> 
> 


Mime
View raw message