I've had similar thoughts as Raymond, wanting to use annotations for service
matching. And as Neil points out I agree there are many "reflection-like"
scenarios where a bundle can actually be very interested in a set of
unrelated services that fulfill some declarative condition (be that xml,
annotations, or something else).
ISTM a natural extension to the OSGi platform would be to offer API for a
programmatic filter, to complement the current declarative filter. Something
like
public interface ProgrammaticFilter {
boolean matches(<some sort of service event or reference here>)
}
that could be used for scenarios where the declarative filters don't get you
all the way. F ex, this kind of filter could choose to examine annotations
on interface classes found through services' OBJECT_CLASS property.
Of course, in your own code the above is possible today without inventing a
new filter type, but my thinking is that there would be a benefit to enable
this in the plaform, so programmatic filters could be used anywhere where
there is a filter property. There would have to be some way to register and
refer to programmatic filters, and maybe even a way for them to accept
parameters. Then it would be easy to write your own universal
AnnotationFilter that accepts an annotaion specification as input.
Wrt run-time semantics, I'm thinking that it would be appropriate for the
framework to only query these ProgrammaticFilters once per service, so the
facility doesn't grow into some super-dynamic "status check" feature. The
goal would be to be able to write imperative code to check static conditions
that are valid throughout the service's lifetime.
Another benefit of an imperative filter approach is that Java types are
available so you can query class hierarchies using isAssignableFrom() and
similar functions.
Best regards
Mike Wilson
Neil Bartlett wrote:
BJ,
There is plenty of utility in tracking untyped services. Gogo shell commands
would be one example. Also there are plenty of JavaEE specs that use
reflection, often guided by further annotations on the methods or fields, to
interact with "untyped" (but annotated) services. JAX-RS for example, and
this reminds me that I intended to write an RFP for OSGi to standardise an
approach for using JAX-RS "services" in OSGi.
Personally I find that recent JavaEE specs obsessively overuse (or even
abuse) annotations to the same extent that early J2EE specs overused XML.
But that's the reality the EEG will have to deal with if we want to expand
coverage of the Java enterprise world.
Probably the best practical approach for now is to apply a transformation at
build time. This could be done with a bnd plugin that inspects the
annotations and generates entries in the manifest and/or DS XML declaration
to publish the annotated class as a service with properties.
Regards,
Neil
On Thu, Jun 27, 2013 at 9:04 PM, BJ Hargrave <[email protected]> wrote:
I don't see the utility of tracking untyped services since you can't really
use them :-)
In any case, I don't expect any changes to ServiceTracker regarding
annotations. ServiceTracker tracks service based upon information visible in
a ServiceReference (via ServiceEvents sent to ServiceListeners). An
annotation on the implementation class or interface under which the service
is registered is not visible in a ServiceReference.
What you want to do should be done with service properties. Decorate the
interesting service with some service property and then track based upon
that service property.
--
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the <http://www.osgi.org/> OSGi Alliance
<mailto:[email protected]> [email protected]
office: +1 386 848 1781 <tel:%2B1%20386%20848%201781>
mobile: +1 386 848 <tel:%2B1%20386%20848%203788> 3788
From: Raymond Auge <[email protected]>
To: OSGi Developer Mail List <[email protected]>
Date: 2013/06/27 15:19
Subject: Re: [osgi-dev] tracking by annotations
Sent by: [email protected]
_____
This is how I'm tacking them currently:
Filter filter = _bundleContext.createFilter("(!(original.bean=*))");
_serviceTracker = new ServiceTracker<Object, Object>(
_bundleContext, filter, this);
which as you might guess matches lots of services (anything that isn't
explicitly one of these "original.beans".
And so the addingService method actually has to check to see if a match is
annotated and ignore it if it isn't.
I've tried a number of different ways, but none seem to capture just the
subset of annotated services, unless I add even more metadata in addition to
the annotation.
- Ray
On Thu, Jun 27, 2013 at 3:11 PM, Raymond Auge <
<mailto:[email protected]> [email protected]> wrote:
But, how would you write a ServiceTracker do track it?
I need a tracker to get the DS components to collaborate with a non-DS
system.
i.e. the target isn't a component using a @Reference annotation. It's a pure
service tracker.
I'm trying to implement a generic mechanism that allows annotation classes
with an existing web service annotation. When such a class is registered as
a service (in this case using DS annotations), I would like to register it
in our existing web service framework.
These web services don't "infer" any particular type, other than the web
service annotation.
- Ray
On Thu, Jun 27, 2013 at 2:59 PM, BJ Hargrave < <mailto:[email protected]>
[email protected]> wrote:
Well the type of the referenced service can be inferred from the argument to
the method annotated with @Reference.
--
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the <http://www.osgi.org/> OSGi Alliance
<mailto:[email protected]> [email protected]
office: +1 386 848 1781 <tel:%2B1%20386%20848%201781>
mobile: +1 386 848 <tel:%2B1%20386%20848%203788> 3788
From: Raymond Auge < <mailto:[email protected]>
[email protected]>
To: OSGi Developer Mail List < <mailto:[email protected]>
[email protected]>
Date: 2013/06/27 14:53
Subject: [osgi-dev] tracking by annotations
Sent by: <mailto:[email protected]>
[email protected]
_____
Wouldn't it be nice if we could track|filter services by runtime type
annotations?
Currently I can see the only possible solution being something along the
lines of (note these are bnd DS annotations):
@Component(
properties={
"annotation=com.foo.Baz"
},
provide=Object.class
)
@Baz
public class Bar {
}
Nothing else works (such as passing the annotation class via the provide
array).
Note that in this case a complication comes up because the property must be
a constant which means there is a danger if package is refactored.
Thoughts?
--
<http://www.liferay.com/web/raymond.auge/profile> Raymond Augé (@rotty3000)
Senior Software Architect
<http://www.liferay.com/> Liferay, Inc. (@Liferay)
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
