2009/3/18 Fredrik Alströmer <[email protected]> > > 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. >
Hi Fredrik, well one use-case may be to select between multiple implementations of the same API, just like you can do with properties - might not be that common but I could see some apps using this of course if there really is no common API you could either register it using java.lang.Object or the registering code could scan for interfaces and register it under whatever types it found - that could then make it interoperable with other service frameworks which don't know about the annotations (or the annotation processing could be on the registering side which would then discover the types and register the service using them) > 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). > correct you would need a standard if you wanted interoperability but this sounds more like a standard outside of the core, perhaps in the compendium (like the distributed OSGi work) - maybe even an external standard, as this could be useful outside of OSGi (for example, other attribute-based service registries could use it) >> 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. > I assume you meant the suggested annotation spec? - because if you register a service using java.lang.Object then you aren't guaranteeing any particular type for prospective consumers and the OSGi framework doesn't require additional type checking of course the consumer would then have to consider all services unless you flagged them somehow using properties (which is where a standard would come in useful :) so yes, you could standardize how the consuming side should get and process annotation details to enforce the relevant type-safety checks > >> > >> 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. > no, but from the perspective of the application it doesn't really matter whether the annotation object came via an annotated element or was constructed from a local type - especially if you're checking equality for binding purposes (which is how Guice uses it, to great effect) >> (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 still don't see how the spec "stops" you from doing this - you are certainly free to register services using java.lang.Object along with properties processed from annotations (or even get the types from the annotation which would save the consumer from doing this) you'd just have to define a standard somewhere (compendium or external) just like other frameworks that build on OSGi services I guess I'm having a hard time seeing what changes are needed in the core spec / API to support this - which part of the spec is stopping you from prototyping this on top of OSGi? (the benefit of standardizing these sort of ideas outside of the core is that it becomes "opt-in", and you don't force everyone to have to support it, or even deploy, it if they don't need it) >> 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? > this isn't an OSGi specific problem - you get the same issue using JAX-RS with proxies, because the JAX-RS specification forbids you from scanning the hierarchy for certain annotations (they'd be on the proxy superclass) from what I've seen out in the field this is a wider problem that requires a more generic solution, rather than something baked deep into OSGi itself but please don't let that stop you from trying out a prototype, or writing up an RFP - you might want to look at the distributed OSGi work which deals with a lot of similar issues (perhaps you could even use some of the new registry hooks to mix-in annotation processing - see the 4.2 draft spec) > -- > > Cheers, Stuart > > Greetings, > Fredrik. > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > -- Cheers, Stuart
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
