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... 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