Policy and cardinality are part of how you write your code. I.e. code uses a
static policy cannot run correctly when you turn it into dynamic, the same for
cardinality. Code written to understand a single service will fail if you try
to call it with many. You could scale it down (multiple can handle optional and
1) and dynamic could be run statically. However, this asymmetry makes it very
hard to create a configuration model that would not have an large amount of
error cases.
Second, what DS does very well is the hard part of handling service
dependencies. It seems a violation of cohesion to let it do more to cover
specialized use cases. Use the DS primitive, and build further
filtering/processing on top of it. I.e. if you have a certain ordering, it is
trivial to do this in the bind method where the full power of Java is at your
disposal.
The fact that DS works well today is that it just does very little, but it just
does it extremely well. Its popularity makes it an interesting extension point
but I think we should resist turning it into a christmas tree. It should be
treated as an enabler, not as a convenient library.
Kind regards.
Peter Kriens
On 23 mrt. 2014, at 18:15, Balázs Zsoldos <[email protected]> wrote:
> Hi,
>
> a while ago I wrote a mail to this list about the possibility of having
> references where the multiplicity and ordering is configurable.
>
> I would really like to see a solution where my requirements are available. If
> nothing else, I will implement it under a new project.
>
> I would be really interested about suggestions and opinions from others. I
> will explain my ideas as extensions to Declarative Services. However, if it
> does not fit in the logic of DS, I can imagine it in a separate, similar
> technology.
>
> In DS, there is the possibility to add references to a component. Only the
> target is configurable and every other settings must be hard coded. I was
> thinking that some of the other settings should be configurable as well:
> optional, static/dynamic, cardinality. Let's call this configurableReference.
>
> A configurableReference could be configured with clauses. E.g. (type of
> target is String[]):
>
> myReferences.target=
> - myService1;filter:=(service.pid=xxx)
> - myService2;filter:=(service.pid=yyy);resolution:=optional;policy:=static
>
> The example above defines a reference where the cardinality is 1..2. The
> first one is required, the second one is optional. As the second is static,
> the component is restarted each time the second instance changes.
>
> The first part of the clause is the id of the reference: myService1,
> myService2. The id can be retrieved in the bind method as a String parameter
> (or as an entry in the Map of service properties parameter).
>
> With this kind of configuration possibility, it is possible to:
> Define references with multiple cardinality in the way that each piece of
> reference is configured in a different way (policy, cardinality, resolution)
> Use the id to be able to order the instances
>
> Imagine you have a ServletContainer component where you can define services
> and filters. Both are defined as a reference with bind and unbind methods.
> The filters could have the following configuration:
>
> myReferences.target=
> - _01_authenticationFilter;filter:=(service.pid=xxx)
> -
> _02_etagFilter;filter:=(service.pid=yyy);resolution:=optional;policy:=dynamic
>
> Programmers would normally use ConcurrentSkipListMap as a store for service
> instances, based on the id, the services instances could be ordered.
>
> Any thoughts? I know whiteboard pattern with service ranking is supported
> nowadays. but I have the feeling that the configuration possibilities above
> would give the same flexibility in a more deterministic way. Whiteboard
> pattern can get confusing if more containers are used within the same OSGi
> container, while this configuration remains clean.
>
> Although I had an example with servlets. I was talking about every use-case
> where the programmer want to allow others defining possibly ordered set of
> features for their technology:
>
> - Servlets for ServletContainers
> - Filters for Servlets
> - Components for Jersey (I mean component in the meaning of Jersey)
> - Chain of protocols for JGroups (this can definitely not solved with
> whiteboard pattern)
> - Any configurable list (optionally ordered) of features for a solution.
>
> I would be very happy to get any feedback. I am pretty sure that as soon as I
> have some time (in a couple of months) I will start implementing this logic.
> I would be very happy if I could get any feedback (arguments that tell me
> that I was wrong as well).
>
> Regards,
> Balazs Zsoldos
> _______________________________________________
> 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
