Is it possible to "extend" the default behaviours of DS? If so then I could just extend the functionality to simple add a "property" of
annotation=Annotation[] which my own tracker could then use to filter. This would clear developers of having to add yet more, redundant, metadata to their classes. - Ray On Thu, Jun 27, 2013 at 4:40 PM, Neil Bartlett <[email protected]> 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 *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 >> > > > _______________________________________________ > 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
