+0 for 2), as I do not fully get the implications/possible issues of using ThreadLocal, but also do not like the current way of passing context to method calls.
Regards, Jerome > 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 > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
