> 2009/3/17 Fredrik Alströmer <[email protected]> >> >> Hi, >> >> I'm sure this has already been discussed, but I was working with some >> stuff that was using annotations, when it hit me that it's rather >> inconvenient to publish an OSGi service based on an annotation. You'd >> have to publish it using java.lang.Object, > > I don't see why you couldn't publish the service instance > as normal - ie. if you just want to filter on the annotation > then add it to the service properties under a known key > > also wouldn't you still have an API in mind when using the > service? clients would still presumably cast the service to > a known type before using it, so use that type > > perhaps an example would help explain your use-case?
I might be somewhat ignorant here, but I can't think of an annotation being used where the object is required to implement an interface, most that I know are used as markers to trigger an analysis through reflection (cf. @WebService). Since you cannot 'use' the annotation itself (or can you?) except through reflection, this makes sense to me. A known key works if I'm in control of both sides of the service registry, however, the goal should be that I'm not, and thus that key needs to be agreed upon (i.e. standardized, whether in the spec or as de facto standard). >> and come up with some (not standardized) property to contain the FQ-name >> of the annotation. > > or an array of names if you want to be flexible and filter > on more than one annotation at a time, like objectclass > does with types True. >> >> There's also no 'type-safety' involved which checks to see if the >> class of the returned service-object does indeed carry the required >> annotation. > > you could add this check in whatever framework is adding > the annotation information to service properties - I don't > believe it requires any change to the minimal OSGi core Of course you can, but the spec requires type checking of the service object, using the same reasoning, this would require standardization as well. >> >> Considering that it's not possible to 'implement' an annotation > > actually it is possible to implement annotations, you > just have to follow the specification from the javadoc: > > > http://java.sun.com/javase/6/docs/api/java/lang/annotation/Annotation.html > > Guice does this (it has @Named and NamedImpl.class) Interesting, but then again extending this interface "does NOT define an annotation type", neither is it an annotation itself, so implementing the interface 'Annotation' does not implement an annotation (which would be sort of self contradictory), just an interface with that name. >> (which would produce clashes), would it be a viable addition to the spec >> to >> allow service objects to be registered (extrapolate as needed to >> service factories) using an FQ-name of an annotation as >> 'interface'-name, where the framework is responsible for checking that >> said service object does indeed carry the annotation? This is of >> course assuming that annotations are supported in the runtime >> environment, but it does not impose such an assumption on any >> interfaces, and so the spec is still valid in pre-annotation >> environments. As far as I can tell, annotations are used primarily >> (only?) in combination with reflection, so there's no real reason to >> provide an actual type-check. > > personally I'd see this as something optional on top of the core > OSGi spec - afaik there's no reason why you couldn't implement > this today using existing APIs The APIs allow this, the spec on the other hand does not, as has been pointed out. You would have to register using java.lang.Object and the aforementioned 'known,' non-standard, parameter. >> I can see that there might be concerns in the general direction of >> proxy objects, but then again, I believe those have a problem in >> general with respect to annotations? > > generally yes, but as Neil pointed out most OSGi service instances > are not proxied - it's left up to the OSGi framework to decide whether > it wants to do any proxying (most don't) > > however, component models built on top of OSGi do use proxies > (but again, not all the time - it depends on the circumstances) I just wanted to highlight the fact that implementing this scheme might throw a monkey wrench into the gears of frameworks based on proxies (a proxy can implement an interface, but I don't think it can carry an annotation). For example (a completely contrived example that I just made up), consider a remote service framework (lets call it RSF), where a service is registered using an interface AND an annotation. This is picked up by the RSF and the service registration is mirrored at the remote location using a service factory and/or proxies (registering it using two different registrations, one for annotation and one for interface would not have this problem). Using this service would fail if an annotation check is performed. But perhaps this is an acceptable limitation? > -- > Cheers, Stuart Greetings, Fredrik. _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
