13 Apr
2008
13 Apr
'08
11:13 a.m.
Hi Vincent,
I recently had an issue with 2 in the following context:
- the framework, in this case exo, expects the container in ThreadLocal
- the component we wished to integrate (a webapp) relied upon its own
thread management for some lower level processing part of which needs
to call the exo platform through an adapter
We initially did not know that the framework depended on this, but
after some exchanges with the exo team we tried the approach they use
in their exo applications which is to setup the ThreadLocal with a
servlet filter. This did not work because of course the adapter thread
did not have its ThreadLocal setup. We finally ended up putting the
setup code in the adapter thread, because in this case it was the only
point of interaction with exo, but there could have been other points
of interaction, and so its not a general solution.
So in conclusion, my experience is that the technique really needs to
be well documented, especially if wiki level scripting or plugins may
need this type of callback behavior to the xwiki framework through
other frameworks that manage their own threads.
P.S. Didn't know about InheritedThreadLocal, sounds cool.
Luis
On Sat, Apr 12, 2008 at 11:25 AM, Vincent Massol <vincent(a)massol.net> wrote:
Hi,
In the new xwiki architecture we need to take a call for passing the
request, response and session around (what is currently called the
XWikiContext). We have 2 solutions:
1) we pass it around for all method calls as it's currently done
2) we use ThreadLocal(s). If you don't know what it is see for ex:
http://crazybob.org/2006/07/hard-core-java-threadlocal.html
.
The advantage of solution 2) is that any component in the new
architecture can decide to have the Container component injected (see
http://svn.xwiki.org/svnroot/xwiki/xwiki-platform/core/trunk/xwiki-containe…)
and thus be allowed to access the request, response and session
objects without having all its method add a Container object passed to
it.
The downside of solution 2) is simply that we associate Unit Of Work
with Threads. But since we use a Servlet model and since I don't see
any foreseeable future where we would want to use several threads for
the same unit of work, I don't think this is limitating for us. See
http://blog.objectmentor.com/articles/2007/09/04/thread-local-a-convenient-…
for some explanation on this.
So right now and even though ThreadLocal sound a little bit "hackish",
I think this is still my preference as it'll save us from having to
pass Container objects everywhere.
Since this is an important architecture decision I wanted to have a
vote for it.
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Luis Arias
+33 6 14 20 87 93
skype : kaaloo