I'd suggest simply using the whiteboard pattern. It would look like:
Bundle A: if optional O becomes available, it publishes a O[A] service to the registry Bundle B, if optional O becomes available, it tracks and uses services O[*] Either way, both bundles can run individually, but collaborate when their options are satisfied. - Ray On Tue, Jun 3, 2014 at 8:32 AM, Mike Wilson <[email protected]> wrote: > I'm looking at the generic problem of one optional bundle wanting to affect > the behaviour of another optional bundle's service, without hard-wiring > these bundles too much to each other. Each bundle should be deployable by > itself in a system, but when both are available they should be able to hook > into each other to affect the outcome of calls made on them by other > bundles. > > As I have control over source code myself the first alternative that comes > to mind is the "cooperative" style where each bundle could provide a custom > Hook interface that others may implement. When executing calls from other > bundles these Hook implementations could then be consulted for modifying > the > result of the operation. This seems to be in the spirit of many parts of > core OSGi. > > Or, I could skip on the cooperative style and rely on framework > ServiceHooks > and proxies, which seems to be more hackish but may have advantages? > > Or are there other, better, alternatives? > > Thanks > Mike Wilson > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay)
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
