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

[rfc 172] Annotations for Declarative Services #1400

Closed bjhargrave closed 12 years ago

bjhargrave commented 14 years ago

Original bug ID: BZ#1501 From: @pkriens Reported version: R4 V4.2

bjhargrave commented 14 years ago

Comment author: @pkriens

Both bnd and Felix have created annotations to markup a DS component. These annotations are very popular because they really take a lot of pain out of making components. We need to standardize these annotations.

It could also make sense to define an annotation for Exported packages to replace packageinfo.

bjhargrave commented 14 years ago

Comment author: Richard Hall <richard.s.hall@sun.com>

They could also be used by other approaches like iPOJO.

Will we be reinventing JSR 299?

bjhargrave commented 14 years ago

Comment author: @bjhargrave

Will we be reinventing JSR 299?

Let's reinvent JSR 330!

bjhargrave commented 14 years ago

Comment author: Richard Hall <richard.s.hall@sun.com>

Yeah, JSR 330 is the one I actually meant...although JSR 299 has DI stuff in it too, so there is plenty of reinvention going on. :-)

bjhargrave commented 14 years ago

Comment author: @pkriens

I see you guys have deeply thought about this subject and extensively studied the respective JSRs. Thanks!

Could both of you add to this bug report a description of how we could do dynamic dependencies with @ Inject? Can we do this with a @ Scope annotation? And not sure how to find out the implementation class of the component?

bjhargrave commented 14 years ago

Comment author: john_arthorne@ca.ibm.com

We have been using JSR-330 annotations in Eclipse e4, and while the annotations are a good starting point, the specification leaves many unanswered questions when dealing with dynamic services. For example they say nothing about "uninjecting", or the lifecycle of the interaction between injector and injectee (such as @ PreDestroy and @ PostConstruct). After making our injection conform to the TCK found at [1] we still had many test cases where we had to figure out reasonable behaviour for ourselves. This of course limits portability which defeats some of the value of standard annotations. So, I think there is certainly some value in having a specification on behaviour of DI in a dynamic service environment.

Having said all that, I'm not sure OSGI-specific annotations are the way to go here. A big advantage of the most recent DS spec is that it allows pure POJO code with absolutely no dependency on or knowledge of OSGi. This isn't a big deal for those of us who have completely bought into OSGi, but it is very interesting for those who want to keep their application code free from specific container dependencies (one of the theoretical reasons for using DI in the first place). I suppose a move from bnd or Felix-specific annotations to more general OSGi annotations is a step in the right direction though.

[1] http://code.google.com/p/atinject/

bjhargrave commented 14 years ago

Comment author: Richard Hall <richard.s.hall@sun.com>

Yes, I agree that standard annotations make sense if and where possible. That was the point of my original comment. And even my "reinventing" comment was not intended as an argument against, rather it was pointing to these other technologies as a starting point.

bjhargrave commented 14 years ago

Comment author: @bjhargrave

CPEG call: The original point of this bug was requesting class retention annotations that tooling would use to generate a component.xml file for DS. Not that DS runtime would use the annotations.

Two questions were raised during discussion:

1) Should the annotations be made more general than DS. For example, could the annotations be used by tooling to generate iPojo or Blueprint metadata?

2) Should the annotations have runtime retention to allow some future runtime to use the annotations directly.

bjhargrave commented 13 years ago

Comment author: @bjhargrave

RFP 145 has been opened.

Also RFC 172.

bjhargrave commented 13 years ago

Comment author: @bjhargrave

RFP 145 was approved. RFC 172 is complete and out for CPEG voting. It has been updated to cover the changes in RFC 176 DS 1.2.

bjhargrave commented 12 years ago

Comment author: @bjhargrave

RFC 172 was approved and has been incorporated in the latest Compendium draft spec.