> From: Mike Wilson <[email protected]> > Please excuse if I am misinterpreting your reply, but I think you > are referring to the fact that ThreadLocals can only be accessed by > the owning thread. This is thought to work in my example as > AsyncTaskHook.wrapQueueTask() is executed on the same thread as > AsyncTaskService.queueTask(), and thus has access to the > ThreadLocals. The shown hook implementation is incomplete (forgot to > add that to the example, sorry...) as there should really be a > constructor on the wrapper Runnable that extracts and saves the > ThreadLocal data and keeps it until run() is called.
I think this is just a bad example. The async task even if wrapped can't mutate the thread locals of the original thread which seems to be the point of your ContextualService. So even attempting to push some of that work off to an async task seems wrong. > > There is one thing I guess I can't get in this design; knowledge > that my Hook has been registered. It will be in the service registry, no? > In a startup scenario where all > three bundles have just started, and MyBundle.myMethod() executes, I > can't be sure that AsyncTaskService has registered my Hook and thus > started considering the contextual workaround? Well your mymethod bundles cannot even know about the hook since it came from some other bundle. As the hook also is a service from a bundle, that bundle can be stopped at any time (for updating as an example). > > If I want to be sure about this, I guess I need to switch to > explicit registration with AsyncTaskService (not whiteboard), and > delay publishing my ContextualService until I know my Hook has been > registered. Or are there ways to make this work with a whiteboard design? Well if the ContextualService requires the hook, how is the hook an optional thing (the subject line of this thread)? -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [email protected] office: +1 386 848 1781 mobile: +1 386 848 3788
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
