13 Apr
2008
13 Apr
'08
1:09 a.m.
On Apr 13, 2008, at 1:03 AM, Pascal Voitot wrote:
see below
On 4/12/08, Vincent Massol <vincent(a)massol.net> wrote:
XWikiContext (current) = request + response + session + app context
(new)
Thanks
-Vincent
On Apr 12, 2008, at 2:05 PM, Pascal Voitot wrote:
No no, I was speaking about context as XWikiContext or as Container
now... After looking at the code, I see what you mean
and the model seems
quite
generic and on the good way!
Excuse me for my stupid ideas... wouldn't it be possible to do the
same for
the context?
You mean application context? If so then it doesn't mean anything
since the application context is the same for the whole duration of
the application. The ThreadLocal is only required for request/
response
and session since those are different per user (thus per thread).
As you say , for AppContext, it means nothing...
I was also speaking about an abstract design to inject the container
in
components without be forced to pass it to all functions...
ThreadLocal would be an implementation of this "container injector"
but as
it might have counter effects that we don't see today, we should
keep the
abstraction so that we can replace it if we find something else...
I'm going to study a bit and think about all of this :)
regards
Pascal
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
The idea is not to be forced to pass it to every
call... Could
it be possible to create an abstract and generic mechanism that
passes
context and one implementation would be ThreadLocal... And if later,
we
discover a strong problem, we could have another implementation...
regards
Pascal
On 4/12/08, Vincent Massol <vincent(a)massol.net> wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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
>>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs