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?
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
>>
>
