Yes, whiteboarding is what I had in mind in my first alternative when publishing implementations of the Hook interface. So I assume you are recommending this alternative? Best regards Mike Raymond Auge wrote:
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 -- <http://www.liferay.com/web/raymond.auge/profile> Raymond Augé (@rotty3000) Senior Software Architect <http://www.liferay.com> Liferay, Inc. (@Liferay)
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
