On Apr 12, 2008, at 1:01 PM, rssh wrote: > On Sat, 12 Apr 2008 12:31:12 +0200, Vincent Massol wrote >> Hi Ruslan, >> >> On Apr 12, 2008, at 12:02 PM, rssh wrote: >> >>> On Sat, 12 Apr 2008 11:25:29 +0200, Vincent Massol wrote >>>> Hi, >>>> >>> >>> Sorry, may be this is not my question, but: I can imagine situation, >>> where >>> ThreadLocal approach will fail: it's when we do asynchronics call >>> to some >>> external entity with callback. In such case callback will not >>> receive context in >>> ThreadLocal. And it is possible (and very common approach) to do >>> this from >>> groovy scripts (as groovy has closures). >> >> I don't understand what would not work... Would you mind giving some >> details and use cases? >> > > For example - write something like 'doParallel' from > http://www.jroller.com/melix/entry/simplifiying_java_util_concurrent_with > > It is common to call long external process in one branch (for > example fetching > external URL) and check for timeout in other branch. > > All closures, which would evaluated inside doParallel will have not > access to > ThreadLocal.
I don't think we should allow user code in document pages the ability to create threads. This is going to be asking for trouble IMO (Remember that inside a J2EE container you're not allowed to manipulate threads). However even if we do we can use InheritableThreadLocal as pointed out by Artem for example. -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
