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<https://jersey.java.net/apidocs/2.6/jersey/org/glassfish/jersey/server/ResourceConfig.html#register(java.lang.Object)> for Jersey (I mean component in the meaning of Jersey) - Chain of protocols<http://www.jgroups.org/javadoc/org/jgroups/stack/Protocol.html> 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
