Even if I can't say I'm an expert of XWiki yet, let me give my point of view... The ThreadLocal is interesting but can bring lots of design constraints also... Moreover, I think the stateless approach would be an insurance for future evolutions and passing the context seems better for that... For example, I have been thinking about an XWiki engine using service oriented approach... without the Servlet model... A raw XWiki service provider without knowledge of its communication and presentation layers... Like this, it would be easy to imagine P2P, balancing, grid computing etc... To my mind, the component model goes in this way...
ThreadLocal and stateless approach may be compliant but I'm sure about this :) Pascal On 4/12/08, rssh <[EMAIL PROTECTED]> 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). > > > > -- > Ruslan Shevchenko > GradSoft. http://www.gradsoft.ua > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
