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] Create separate Service annotation #2008

Closed bjhargrave closed 11 years ago

bjhargrave commented 13 years ago

Original bug ID: BZ#2140 From: Felix Meschberger <fmeschbe@adobe.com> Reported version: R4 V4.3

bjhargrave commented 13 years ago

Comment author: Felix Meschberger <fmeschbe@adobe.com>

The current draft defines a "service" attribute on the component annotation which defaults to all directly implemented interfaces of the class

I think it would be better to separate more between components and services and create a separate Service annotation. If just the Component annotation is present, its not registered as a service With the Service annotation its possible register the component as a service. The Service annotation should have a class or value attribute. If that is left empty, the component is registered for all interfaces or all directly implemented interfaces (whether all or all directly implemented might be another discussion).

Especially the default of not specifying the service attribute on the Component is error prone as its not intuitive. Not specifying something should mean: this is no service :)

For example the Apache Felix SCR annotations has such a separate Service annotation:

http://felix.apache.org/site/scr-annotations.html#SCRAnnotations-Service

bjhargrave commented 13 years ago

Comment author: @pkriens

I really prefer to keep the additional types minimal. In my experience the current model work pretty well

@ Component -> default all implemented interfaces (except ScalaObject) @ Component(service=X.class) -> only X service @ Component(service={}) -> no service

Seems to be easy to read and since a service is an integral part of the component I do not see a good reason to separate them?

bjhargrave commented 13 years ago

Comment author: Felix Meschberger <fmeschbe@adobe.com>

Although the service functionality clutters the @ Component annotation, I could probably live with it. But I would prefer the default for a missing attribute to be a no-service component.

The problem really is the convenience case of just declaring a component a service of the implemented interfaces. Here the separate annotation comes in very handy:

-- No annotation --> no service -- @ Service() (empty value) --> all implemented interfaces -- @ Service(X.class, Y.class) --> explicit list

bjhargrave commented 13 years ago

Comment author: Richard Hall <heavy@ungoverned.org>

Ultimately, I agree with Felix. iPOJO uses separate annotations too, although in iPOJO's case it is @ Component and @ Provides, which fit nicely with @ Requires. From my point of view, this is a nicer separation of concerns.

bjhargrave commented 12 years ago

Comment author: @pkriens

Since when do you use annotations on DS?

bjhargrave commented 12 years ago

Comment author: Richard Hall <heavy@ungoverned.org>

Is that question directed at me? Not sure how to respond. I've been doing this OSGi dependency injection stuff longer than anyone, so I think that qualifies me to have an opinion.

bjhargrave commented 12 years ago

Comment author: Felix Meschberger <fmeschbe@adobe.com>

We are using Java annotations and previously JavaDoc tags with the Maven SCR plugin from the Apache Felix projects for more than 4 years: The initial check-in of the plugin (JavaDoc tags only at that time) dates back to 3. Aug 2007 (http://svn.apache.org/viewvc?view=revision&revision=562420).

The currently supported annotations are modeled after the JavaDoc tags.

bjhargrave commented 12 years ago

Comment author: @bjhargrave

RFC 172 is final and has been approved by CPEG. Since we plan to close the Compendium 4.3 spec this week, it is too late to consider this bug for the Compendium 4.3 release. The only alternative would be to defer DS annotations from the Compendium 4.3 release which I do not want to do.

bjhargrave commented 12 years ago

Comment author: Felix Meschberger <fmeschbe@adobe.com>

So I suggest to keep this as a proposal for the next release.

bjhargrave commented 12 years ago

Comment author: @bjhargrave

So I suggest to keep this as a proposal for the next release.

Which is why I left the bug open :-)

bjhargrave commented 11 years ago

Comment author: @bjhargrave

CPEG meeting: Agreed not to do this in RFC 190.