Another solution to your problem is to use 3 <reference> elements. Each having the target for a different myExtension. Then each reference must be satisfied, so you are guaranteed at least one of each myExtension. You will probably need to hand write the component xml if you want to use the same bind method for all the references. Otherwise you can write 3 different bind methods and annotate each. --
BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance hargr...@us.ibm.com office: +1 386 848 1781 mobile: +1 386 848 3788 From: BJ Hargrave/Austin/IBM@IBMUS To: OSGi Developer Mail List <osgi-dev@mail.osgi.org> Date: 2014/02/26 10:30 Subject: Re: [osgi-dev] Declarative Services and references with configurable cardinality Sent by: osgi-dev-boun...@mail.osgi.org Yes, you would need a compound expression like you suggest. The RFC is not closed but DS will not do every possible way of using services. It is to help with more normal service use patterns (80% rule). If you have a very special need for services, there is still the OSGi API and Service Tracker. You can also look at Felix Dependency Manager [1] which provide an API means to express your service dependencies. Your use case seems very specialized to me and I don't see that changing DS to support it is necessarily best for DS. In many ways, DS is already getting overly complex. [1] https://felix.apache.org/site/apache-felix-dependency-manager.html -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance hargr...@us.ibm.com office: +1 386 848 1781 mobile: +1 386 848 3788 From: Balázs Zsoldos <balazs.zsol...@everit.biz> To: OSGi Developer Mail List <osgi-dev@mail.osgi.org> Date: 2014/02/26 07:17 Subject: Re: [osgi-dev] Declarative Services and references with configurable cardinality Sent by: osgi-dev-boun...@mail.osgi.org Would it work in the way than that I have to define an OSGi filter concatenated with OR logical expressions and provide the minimum cardinality? This seems to be a bit tricky to me. Imagine that the deployer needs three references: - (service.pid=myExtension1) - (service.pid=myExtension2) - (service.pid=myExtension3) As much as I understand, the deployer should define the target to be " (|(extensionType=myExtension1)(extensionType=myExtension2)(extensionType=myExtension3)) " and specify the minimum cardinality to be 3. With this kind of confiration, it might happen that for one of the extension types there are multiple references available while there is no reference for the other extension type. I think it would be more clear for the deployer to say that the referenceName.target can have a value String[] and for each filter in the array one reference should be available. Is the "minimum cardinality" concept written in stone or there is still time to come up with ideas? Regards, Balazs Zsoldos On Wed, Feb 26, 2014 at 1:01 PM, BJ Hargrave <hargr...@us.ibm.com> wrote: 5.10 is the design to solve the problem described in 3.4. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance hargr...@us.ibm.com office: +1 386 848 1781 mobile: +1 386 848 3788 From: Balázs Zsoldos <balazs.zsol...@everit.biz> To: OSGi Developer Mail List <osgi-dev@mail.osgi.org> Date: 2014/02/26 06:43 Subject: Re: [osgi-dev] Declarative Services and references with configurable cardinality Sent by: osgi-dev-boun...@mail.osgi.org Thanks! As much as I see (after a couple of minutes reading), chapter 3.4 is the one I was looking for. On Wed, Feb 26, 2014 at 12:22 PM, BJ Hargrave <hargr...@us.ibm.com> wrote: Have you seen 5.10 of RFC 190 [1] ? [1] https://github.com/osgi/design/raw/master/rfcs/rfc0190/rfc-0190-Declarative_Services_Enhancements.pdf -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance hargr...@us.ibm.com office: +1 386 848 1781 mobile: +1 386 848 3788 From: Balázs Zsoldos <balazs.zsol...@everit.biz> To: OSGi Developer Mail List <osgi-dev@mail.osgi.org> Date: 2014/02/26 04:47 Subject: [osgi-dev] Declarative Services and references with configurable cardinality Sent by: osgi-dev-boun...@mail.osgi.org Hi, an issue came up a couple of times that I could not solve with Declarative Services. First, I thought I had a very special use-case but it came up more and more times so I think it is time to share my thoughts. Imagine you have a servlet container as a component. The component will be instantiated if there is configuration and it will listen on the configured port. You want to specify the servlets that are available on that server instance. If you use whiteboard pattern, that does not make sure that all of the servlets are available at the time the server is started. What I was imagine is to create in the ServerComponent an array references: @Property(name="servlet.target", cardinality = 1) @Reference(cardinality = ReferenceCardinality.MANDATORY_BY_CONFIGURATION) Servlet[] servlet Now if the property servlet.target has the following value servlet.target = {"(servletName=myServlet1)", "(servletName=myServlet2)"} than the component will be active when the two servlet OSGi services are available that match the OSGi filters defined in the property. The logic comes up very often. Every time, when we want to allow extension points in our components in the way that our component should start only when all the configured extension points are available, this feature would be really helpful. What do you think? Regards, Balazs Zsoldos _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
