So based on the first alternative I made up the below example as an
illustration.
Let's say I have two services in my system:
ContextualService (stores data in ThreadLocal)
AsyncTaskService (runs tasks in separate threads)
that are used by one of my other bundles:
MyBundle.myMethod() {
contextualService.doStuff();
asyncTaskService.queueTask(new Runnable() {
public void run() {
contextualService.doMoreStuff(); // fails
}
});
}
then the call to doMoreStuff() will fail as the ThreadLocal is not available
in the async thread. To solve this, AsyncTaskService could offer a Hook
interface that ContextualService implements:
interface AsyncTaskHook {
Runnable wrapQueueTask(Runnable r);
}
class ContextualServiceAsyncTaskHook
implements AsyncTaskHook {
public Runnable wrapQueueTask(Runnable r) {
return new Runnable() {
public void run() {
<set up ThreadLocals>
<invoke original runnable>
<clear ThreadLocals>
}
});
}
}
registerService(new ContextualServiceAsyncTaskHook());
that AsyncTaskService discovers whiteboard-style and invokes on every call
to its queueTask method.
Does this example make sense?
Thanks
Mike
________________________________
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
