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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
