ServiceListener I suppose.. testing.
On Thu, Jun 27, 2013 at 4:49 PM, Raymond Auge <[email protected]>wrote: > 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) > > -- *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
