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