Vincent Massol 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. >
After reading all the comments on this topic, I agree that we should use ThreadLocal (inheritable) objects. The biggest problem seems to be what to do with background tasks. Well, the problem would be that the context is not up-to-date, and some context objects are missing, but that is also true if we pass the XWikiContext around. We should document that starting asynchronous/background threads might lose the context, so the code should not rely on always having the full context there. We should also have a way to retrieve request-independent up2date component instances (like storage, data model, notification manager...). -- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
