12 Apr
2008
12 Apr
'08
1:43 p.m.
Hi Pascal,
On Apr 12, 2008, at 12:35 PM, Pascal Voitot wrote:
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...
Actually we're not bound to the Servlet model at all. If you check the
container component in SNV you'll see that it's made to be generic
with a first implementation for Servlet (in component-servlet).
The only constraint is that whatever your development model you must
provide an implementation of the Container API, i.e. implement the
notion of request, response, session and application context. This is
what we'll do for example in the scheduler or XMLRPC module.
To be honest, I still need to finish this container component since I
don't fully know yet how the correct implementation can be passed to
the component needing the Container object.
Thanks
-Vincent
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
>