search

osgi / bugzilla-archive

Archive of OSGi Alliance Specification Bugzilla bugs. The Specification Bugzilla system was decommissioned with the move to GitHub. The issues in this repository are imported from the Specification Bugzilla system for archival purposes.
0 stars 1 forks source link

[DS] Extending service-factory behavior #834

Closed bjhargrave closed 15 years ago

bjhargrave commented 15 years ago

Original bug ID: BZ#935 From: Fredrik Alströmer <fredrik.alstroemer@sap.com> Reported version: R4 V4.1

bjhargrave commented 15 years ago

Comment author: Fredrik Alströmer <fredrik.alstroemer@sap.com>

Hi!

Are there any plans to change the DS-specification in such a way, that, if the component implementation class implements ServiceFactory, getService is called on it instead of just instantiating and returning the object itself? I'm not sure exactly how this would work with activate etc, but maybe someone has given it a bit of thought?

A possible use-case for this is to have a SCR handle all the dependency management, but still have the component itself decide what object should be returned, allowing the lifecycle to be separated from the actual service object.

Another one could be to have a component exposing multiple interfaces which, for whatever reason, are implemented in different classes with coupled lifecycle (this is probably slightly different requirement though, as this would, I guess, require multiple services to be registered instead of one with multiple interfaces).

bjhargrave commented 15 years ago

Comment author: @bjhargrave

CPEG call: We discussed this and it felt out of scope for DS. DS is not meant to cover all possible use cases with services. But rather the most common cases. Also, a goal of DS was to allow the programmer to avoid using OSGi API, so called POJOs. Many of the changes in RFC 134 complete that goal. But this bug suggestion does fit there since the impl class must implement ServiceFactory. So CPEG agreed that this idea does not fit well with DS at this time.

bjhargrave commented 15 years ago

Comment author: Fredrik Alströmer <fredrik.alstroemer@sap.com>

CPEG call: We discussed this and it felt out of scope for DS. DS is not meant to cover all possible use cases with services. But rather the most common cases. Also, a goal of DS was to allow the programmer to avoid using OSGi API, so called POJOs. Many of the changes in RFC 134 complete that goal. But this bug suggestion does fit there since the impl class must implement ServiceFactory. So CPEG agreed that this idea does not fit well with DS at this time.

I understand the reasoning behind this, however, I believe that such a set up (or similar) is indeed necessary if you'd like to use existing libraries in OSGi by just wrapping them as declarative services. There are several libraries offering more than one interface, where it's not possible to simply instantiate an implementation accommodating all interfaces, still the life cycle is tightly coupled (i.e. one instantiates the others when started), so you can't have multiple declarative services either.

I do not agree that because the class would have to implement an OSGi API, it does not qualify for DS, as currently you may implement the API activate/deactivate with ComponentContext, and you may implement bind methods using ServiceReferences. They're of course all voluntary, but so would the ServiceFactory (or any other solution) be, and it would allow you to separate the OSGi API from the implementation completely, which is not possible with DS today if your service has a life cycle and/or is parametrized with properties.

bjhargrave commented 15 years ago

Comment author: Stoyan Boshev <s.boshev@prosyst.com>

I agree with Fredrik. I think this would be a valuable feature of DS. This could be easily implemented in DS impl.