There are some inaccuracies in what Christian wrote.
> On Mar 28, 2017, at 2:19 AM, Christian Schneider <ch...@die-schneider.net>
> wrote:
>
> On 28.03.2017 11:07, erwan wrote:
>> Hello,
>> Coming back again to get light!
>> I have a bundle of questions regarding DS.
>> How do you use a service without being yourself a service?
> You can not use a service without being a service in DS. You can hide your
> service though.
> If you set serviceClass to a class in a private package then no other bundle
> can use this service.
> So this works nicely if you have some internal wiring.
A DS component does not have to expose any service interfaces. Such a
component will not be registered as a service. It will be immediate and a
singleton.
If you are using the DS spec annotations, the default service property is all
the directly implemented interfaces of your class, so if there are no such
interfaces, by default your component will not be registered as a service;
otherwise you have to specify service={} in the @Component annotation.
>>
>> I understand that each service is managed by the scr and so need to be
>> activated at a time. If I have a class that need to do a reference to a
>> service but that I want to control instantiation, is this possible to
>> instantiate a service on demand (newInstance?) ?
> I think you can create a DS component instance programmatically but I do not
> remember any more how to do it exactly.
You can try to use a factory component but these have a very peculiar lifecycle
that in my experience makes them impossible to understand and useless. For
instance, I’ve been trying to explain their behavior for a couple months to
someone on the felix lists. There’s a felix-proprietary extension
@DSExt.PersistentFactoryComponent that makes the lifecycle like a normal
component, but I would strongly advise seeking another solution.
I would consider whether some combination of configuring several service
instances of the same DS component using factory configurations and/or using
prototype scope would meet your needs.
>>
>> How do you manage to deal with multiple instances of a service?
>> For example:
>>
>> class dummy {
>>
>> @Reference
>> private Service service1
>>
>> @Reference
>> private Service service2
>>
>> }
>
> For this case you typically use a filter and set a service property on each
> of the implementing classes.
>
> Btw you can even set a service property for a DS service that you have not
> written.
> See
> http://liquid-reality.de/display/liquid/2016/09/27/Some+hints+to+boost+your+productivity+with+declarative+services
> Paragraph "Override service properties using config “
This reference is mostly correct except for claiming that components must
expose services. I think it would be helpful if it provided an example of
filter syntax (people often leave off the parentheses the first time) and
pointed out that all the @Reference choices are available for the event
strategy (and indeed lookup strategy) by explicitly specifying them in the
@Reference annotation. While I think it’s pretty likely that constructor
injection will still be in the R7 spec when it comes out I prefer not to assert
such things categorically.
thanks
david jencks
>
> Christian
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
