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!
The only problem is that I haven't found a way to inject the correct implementation of Container in the components that need it. Thus for now the only solution I have is by passing it to every method.... It's the calling code that knows which implementation to pass... Any idea? Thanks -Vincent > Excuse me for my stupid ideas... wouldn't it be possible to do the > same for > the context? 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). _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
