so in fact, you have a kind of ThreadLocalContext (aka Container) containing the local variables (automatically injected etc...) and an ExecutionContext containing "general" variables specific to the execution environment... Am I right?

On Mon, Jun 2, 2008 at 6:08 PM, Vincent Massol <vincent(a)massol.net> wrote: > Hi, > > I've been thinking a lot about the Container component I introduced > and while writing unit tests for some of the new rendering classes I > realized there was something not right: it's not normal that the HTML > exporter or the rendering module depend on the Container object, and > especially on the Request. > > Thus I'd like to introduce the notion of Execution Context (EC in > short). > > The idea is that the xwiki entry points depend on the environment > (Servlet, Portlet, etc) but those entry points create an Execution > Context which is then used by the core components, independently of > the environment. For example the VelocityContext is now put in the EC > and not in the Request object. > > The Container objects still exist and can be used where required but > it's expected that they should not be used since that makes the code > dependent on the environment. > > This solves issue I had with code that don't have a request. > > I have it done on my machine. WDYT? Ok to commit? > > Thanks > -Vincent > > PS: BTW this makes it very similar to the current XWikiContext (which > is good) with the exception that the Container objects are not > located > inside the EC but as separate threadsafe variables.