Closed bjhargrave closed 11 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
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?
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
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.
Comment author: @pkriens
Since when do you use annotations on DS?
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.
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.
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.
Comment author: Felix Meschberger <fmeschbe@adobe.com>
So I suggest to keep this as a proposal for the next release.
Comment author: @bjhargrave
So I suggest to keep this as a proposal for the next release.
Which is why I left the bug open :-)
Comment author: @bjhargrave
CPEG meeting: Agreed not to do this in RFC 190.
Original bug ID: BZ#2140 From: Felix Meschberger <fmeschbe@adobe.com> Reported version: R4 V4.3