On Apr 13, 2008, at 1:03 AM, Pascal Voitot wrote: > see below > > On 4/12/08, Vincent Massol <[EMAIL PROTECTED]> wrote: >> >> >> On Apr 12, 2008, at 2:05 PM, Pascal Voitot wrote: >> >>> 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). > > > No no, I was speaking about context as XWikiContext or as Container > now...
XWikiContext (current) = request + response + session + app context (new) Thanks -Vincent > > 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 >> >>> 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 <[EMAIL PROTECTED]> wrote: >>>> >>>> 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 <[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 >> >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs >> > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
