Vincent, I have a question: do you have idea of who, when and how the right container will be injected as a ThreadLocal? (was it your question "Any idea?"some mails ago?)
I'm drawing some parallel with the hibernate session-per-request model which is easily implemented with ThreadLocal... About InheritableThreadLocal, I found this: "ThreadLocal's less thread-safe cousin, InheritableThreadLocal The ThreadLocal class has a relative, InheritableThreadLocal, which functions in a similar manner, but is suitable for an entirely different sort of application. When a thread is created, if it holds values for any InheritableThreadLocal objects, these values are automatically passed on to the child process as well. If a child process calls get() on an InheritableThreadLocal, it sees the same object as the parent would. To preserve thread-safety, you should use InheritableThreadLocal only for immutable objects (objects whose state will not ever be changed once created), because the object is shared between multiple threads. InheritableThreadLocal is useful for passing data from a parent thread to a child thread, such as a user id, or a transaction id, but not for stateful objects like JDBC Connections." regards Pascal On 4/13/08, Luis Arias <[EMAIL PROTECTED]> wrote: > > 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 <[EMAIL PROTECTED]> > 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-containers/ > ) > > 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-abomination > > 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 > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > -- > Luis Arias > +33 6 14 20 87 93 > skype : kaaloo > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
