I think you both are suggesting same thing. Whiteboard pattern can provide
a way of "hooking" into another entity in the framework. The service
interface you publish the whiteboard service as provides the contract of
the hook.
Tom
From: Raymond Auge <[email protected]>
To: OSGi Developer Mail List <[email protected]>
Date: 06/03/2014 08:51 AM
Subject: Re: [osgi-dev] cooperation between optional bundles
Sent by: [email protected]
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é (@rotty3000)
Senior Software Architect
Liferay, Inc. (@Liferay)
_______________________________________________
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
