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 <rssh(a)gradsoft.com.ua> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs