On 3 jul. 2013, at 23:23, Mike Wilson wrote:
> I sympathize with all motivations being brought up in this thread, both for
> and against (and I appreciate the poetry too :-). I'm quite sure many of my
> observations are affected by my location on the (beginning of) OSGi learning
> curve, having kept an eye on this for a long time but not starting to
> actually work with it until last year. So treat these disparate observations
> with that in mind.
>
> Many Java frameworks today provide both a low-level API (like Core OSGi) and
> a high-level API (like DS) that builds upon the former. Typically, the
> low-level API uses imperative/programmatic style and the high-level
> declarative. With this reasoning in mind while learning OSGi, I did expect
> something more generic and imperative than the declarative LDAP filters in
> the low-level API. Just my 2c.
Interestingly, I hardly every use the filters ... It is paramount that they are
there because certain things require a more narrow selection but in general I
like to design things that whatever service is out there is intended for me;
this is one of the fundamental ideas in OSGi. As Richard Hall said, the bundles
installed are your configuration. Once you need to control the services binding
through filters it gets awkward and complicated VERY quickly.
> The way I'm thinking about programmatic filters are (I think) not easily
> expressable with current constructs. Certainly I can achieve the desired
> goals for my own bundles. But my key point with support for a more generic
> filter is that I can use my custom filter in filter strings that I pass to
> third-party code that is outside of my control. This code can then use my
> custom filter logic even though it just passes on to a ServiceTracker. So in
> this thinking the current LDAP filter can be expressed as a concrete
> implementation of the programmatic filter, but the opposite isn't true.
We have a Filter interface that you can implement your way and pass around
(also to the probably should be deprecated Service Tracker). So not sure what
you miss?
> Annotations are coming. OSGi-CDI is making its way into the standard and
> there are annotation implementations for the other extenders as well. All of
> them will have to implement their own boilerplate. I'm thinking some degree
> of standardized support in the framework would be appropriate, to lead the
> way and to decrease boilerplate.
I think this shows a very common misconception of what OSGi is ... OSGi is not
a library that tries to make your life easier with lots of conveniences. OSGi
is primarily an enabler. The problem with this discussion, and many others, is
that most people do not seem to realize how rich the eco system is; how much
variety exists. They often only see a part of the whole picture and assume
their view is the 100%. It isn't. The only way to keep this rich environment
together is to minimize the base so many different flowers can blossom.
OSGi is not an application environment, it can be used to build an application
environment (think JEE App Servers). It is not a boilerplate preventer, it can
be used to prevent boilerplate (think extenders). OSGi is not about
convenience, it is about providing a fabric for libraries that provide
conveniences for targeted communities. For a lot of enterprise developers it
seems horror that the environment is not bending backwards to be nice to them.
However, I do believe this layering is the only tool we have to keep complexity
and bloat in check; To allow many different communities to share the same
modular Java backplane.
So OSGi should provide enablers, not conveniences. Only if we miss a primitive
to support an important convenience then we should add it to the
specifications. Not to provide this convenience, only to enable this
convenience. This will allow many different parties to develop popular
libraries for their constituents without making the world more complex for
others.
In the mean time, I think the environment is already incredibly rich to allow
much, if not all, of what you want to be done by third party bundles.
Thanks for your reply, this kind of feedback is appreciated. Kind regards,
Peter Kriens
>
> Best regards
> Mike
>
> Peter Kriens 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
