Yup, and so this goes back around: "Wouldn't it be nice if we could track|filter services by runtime type annotations?"
There are plenty of cases where you want to massively classify by annotations rather than by type, hence the world of annotation scanners: Spring, CDI, JPA, etc. - Ray On Thu, Jun 27, 2013 at 4: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 *OSGi Alliance* <http://www.osgi.org/>* > **[email protected]* <[email protected]> > > office: +1 386 848 1781 > mobile: +1 386 848 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 > <*[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 > <*[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 *OSGi Alliance* <http://www.osgi.org/>* > **[email protected]* <[email protected]> > > office: +1 386 848 1781 > mobile: +1 386 848 3788 > > > > > > From: Raymond Auge > <*[email protected]*<[email protected]> > > > To: OSGi Developer Mail List > <*[email protected]*<[email protected]> > > > Date: 2013/06/27 14:53 > Subject: [osgi-dev] tracking by annotations > Sent by: > *[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? > -- * > **Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > (@rotty3000) > Senior Software Architect * > **Liferay, Inc.* <http://www.liferay.com/> (@Liferay) > _______________________________________________ > OSGi Developer Mail List* > **[email protected]* <[email protected]>* > **https://mail.osgi.org/mailman/listinfo/osgi-dev*<https://mail.osgi.org/mailman/listinfo/osgi-dev> > > > _______________________________________________ > OSGi Developer Mail List* > **[email protected]* <[email protected]>* > **https://mail.osgi.org/mailman/listinfo/osgi-dev*<https://mail.osgi.org/mailman/listinfo/osgi-dev> > > > > -- > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > (@rotty3000) > Senior Software Architect > *Liferay, Inc.* <http://www.liferay.com/> (@Liferay) > > > > > -- > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > (@rotty3000) > Senior Software Architect > *Liferay, Inc.* <http://www.liferay.com/> (@Liferay) > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay)
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
