Certainly agreed, the Configuration Admin pattern is really nice when it fits and I am looking at a few places where I would like to introduce it (even though we have standardized on Blueprint, for good or bad).
Still, as you say, there are scenarios where this is not a solution. The Java world is so mind-set on factories that every developer wants to create one and they quickly find Blueprint's "factory-method". So I'm also thinking about alternatives where factories are embedded into the client artifact (the factory will never disappear :-) or trying to push for non-factory alternatives. But I don't have a really clear picture on them yet. Best regards Mike Peter Kriens wrote: > The best practice is not to have factories :-) > > Since factories are so common in 'classic' Java I always see > that designers try to find them in OSGi and become puzzled. > Sometimes this need for factories is valid, in that case you > create a service that acts as a factory. However, many times > there is a MUCH nicer model supported by DS and Configuration > Admin that you really have to 'feel' to see how powerful it > is. Looking at a lot of 'classic' Java, I am often > flabbergasted how complex life there is because they mix life > cycle semantics (factories) with domain semantics; this is > highly uncohesive since these two areas are orthogonal. > Sadly, the API for the life cycle and domain are often in the > same package :-( > > In general, any time you need to configure an instance that > is then used by others is where this pattern is your friend. > > DS components can be instantiated from Configuration Admin > factory configurations. By making your implementations DS > components, you automatically get this factory concept. The > beauty is that the implementation classes remain hidden, you > get full control in deployment, it is dynamic, and best of > all, the rest of your code has no clue, it just reacts to > services. Since the consumers of these services have no clue, > you have an enormous freedom on both side of the service. > > Again, there are valid cases where you want to configure > objects directly, but it is worth a try to see if you can map > this DS/Config Admin factory model; pretty sure you will like it. > > Kind regards, > > Peter Kriens > > > > > On 30 sep. 2014, at 19:06, Mike Wilson <[email protected]> wrote: > > > Another question about best practices :-) > > > > Assuming you have bundles that provide factories allowing > other bundles to > > instantiate objects with behaviour. Typically this would > mean instantiating > > an "Impl" class belonging to the factory classloader and > might also relate > > to resources like network connections. Also assume that > factories are > > exposed as services with separate api and impl bundles. > > > > What alternatives and best practices are there to handle > this correctly when > > updating the factory impl bundle (not the api) and needing > to replace the > > previously generated objects (belonging to the old > classloader) that were > > returned to clients? > > > > And, more specifically: > > > > What alternatives minimize the number of bundles that need > to restart? (as > > opposed to restarting the whole dependency graph) > > > > What alternatives work well with Blueprint? (as BP tends to > hide service > > restarts behind its proxies) > > > > Thanks > > Mike Wilson > > > > _______________________________________________ > > 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
