I'm tending to agree that build time should be fine.
There is no valid run-time reason (in my case at least) due to the fact you
have already decided that you are declaring a component.
However, many are overlooking the fact that "target" of DS Component is not
always a DS Reference, and so can't use type inference of other bind
notations, and this is where it gets a little less elegant. You do
basically have to resort to filtering during addingService().
I was simply trying see if there was an elegant way to eliminate the
obvious redundancy in metadata:
the annotation + property which states that you have an annotation
Since we're already duplicating similar data in the Component "provide"
case (the class exists and so it obviously provides whatever interfaces it
implements, itself, and whatever super classes it extends, and yet we still
need to declare, in many cases an explicit list which duplicates at least
some of the metadata) there seems to be grounds for even more duplication.
Yet, there is a "sane" default behaviour, at least in the bnd case, which
handles the "provide" so well in most cases that you barely have to think
about it.
However, fixing that for annotations is at most a task that should probably
be done from a bnd plugin, and set as a property, which I can accept.
Thank you all for your insights,
- Ray
On Mon, Jul 1, 2013 at 4:42 AM, Marcel Offermans <
[email protected]> wrote:
> I fully agree that we should not add more ways to do the same. In a way we
> already have two ways to do the same when it comes to tracking services:
> you can specify a filter condition AND you can use the addingService or
> bind (or whatever it's called in other DI frameworks) method to filter what
> you want.
>
> The methods have the advantage that you're very flexible. Any complex
> criteria can be written in code. They also have a downside. They are slow
> and cannot be optimised. If you end up with a lot of services in your
> framework, having lots of things that track the registry and need to do
> linear scans over all available services is going to become a huge
> performance bottleneck. In such cases, the filter conditions can be sped up
> by adding indices (just like we optimised relational databases a long time
> ago), method invocations can't.
>
> So what I'm trying to say is that it might make sense to (either at
> compile time or at run-time) inspect the annotations and convert them into
> service properties. Or at least partially, for efficient filtering, to
> recognise that an instance should be further inspected.
>
> Greetings, Marcel
>
>
> On Jul 1, 2013, at 10:14 , Peter Kriens <[email protected]> wrote:
>
> In DS, it is trivial to filter in the bind method with whatever mechanism
> you want to use ... why add more ways of things that can already be done?
> Yes, they might save you a bit of time but all future users have to grock
> this functionality and waste brain cycles deciding if it is applicable for
> them. Your favorite feature is another man's ballast. A spec like OSGi
> should not provide all possible features but should instead focus on the
> 'enablers', the critical functions that allow bundles to collaborate. Nice
> to have features are in the realm of libraries built on top. As Richard
> Hall always said: If you can build it on top, don't include it. Or more
> poetic :-):
>
> Il semble que la perfection soit atteinte non quand il n'y a plus rien à
> ajouter, mais quand il n'y a plus rien à retrancher - Antoine de
> Saint-Exupéry
>
> (It seems that perfection is not achieved when there is nothing left to
> add but only when there is nothing left to remove)
>
>
> Kind regards,
>
> Peter Kriens
>
>
> On 28 jun. 2013, at 13:59, Mike Wilson wrote:
>
> 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 OSGi Alliance
> [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]
> > 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]> 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
> [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 14:53
> Subject: [osgi-dev] tracking by annotations
> Sent by: [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é (@rotty3000)
> Senior Software Architect
> Liferay, Inc. (@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
