The example with Servlets was more like an example. I can imagine many other use-cases: - Jersey component configuration where the Jersey features are configured as references. Whiteboard pattern does not work very well here as a REST class instance may need other Jersey feature to work together with. If you have the chance to configure the set of features as references in a Jersey DS component, you can be sure that your REST API will function well. A jersey feature can be a JSON parser. - You want to deploy a servlet with specific filters. E.g. authentication filters. If the set of filters can be configured as references, you can be sure that the filters will be available when the servlet is accessed - Any other component where you want to deploy several features at the same time with the same instance
While whiteboard pattern gives a great flexibility and fast configuration, it disallowes the deployer to have a clear configuration in more complex systems. It disallowes the programmer to force a set of component instances deployed together into another component (servlets and filters into server component instance). With a big number of components configuration can get magical (3 server instances with 20 servlets with different combinations). Balazs Zsoldos Software Architect Mobile: +36-70/594-92-34 Everit Kft. https://www.everit.biz Everit OpenSource http://everit.org On Wed, Feb 26, 2014 at 12:19 PM, Neil Bartlett <njbartl...@gmail.com>wrote: > Why not just use the whiteboard pattern? You said: "whiteboard ... does > not make sure that all of the servlets are available at the time the server > is started." Why is that important? > > Regards > Neil > > -- > Neil Bartlett > Sent from a phone > > On Wednesday, 26 February 2014 at 09:47, Balázs Zsoldos wrote: > > 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
