On Mon, Aug 10, 2009 at 10:06, Vincent Massol<vincent(a)massol.net> wrote:
 On Aug 10, 2009, at 8:25 AM, Thomas Mortagne wrote:
  Hi devs,
 Remote observation manager receive remote events and convert before
 injecting it in a specific thread. For this to work properly as usual
 the execution context need to be initialized for this thread.
 Initialize ExecutionContext is pretty clean and component oriented but
 we also need a stub XWikiContext initialized in the ExecutionContext.
 I propose to implements a generic stib xwiki context initializer and
 provider: the initializer react to ExecutionContextInitializer, when
 receiving the first ExecutionContext initialization 
 Why the first? ECI is supposed to be called only once. 
"ExecutionContext initialization" = the ECI called by the first
request, the goal is to initialize the provider based on the first
valid XWikiContext
  containing a
 XWikiContext it call XWikiStubContextProvider.initialize to create a
 XWiki context independent from the request but still containing
 scheme/host/port information 
 So you're cloning the XWikiContext passed in the EC or maybe create a
 new one from scratch but copy info from the passed XWikiContext? 
 
A clone with some tweak to emulate Request etc... Look at scheduler
plugin to have a idea of how i plan to create the stub XWikiContext.
  and when ExecutionContextInitializer is
 called with a ExecutionContext which doe snot contains any
 XWikiContext a clone of the stub XWikiContext is injected in the
 Execution context. 
 When would this happen? For ex in Lucene I see:
         ExecutionContextManager ecim =
                 (ExecutionContextManager)
 Utils.getComponent(ExecutionContextManager.class);
         Execution execution = (Execution)
 Utils.getComponent(Execution.class);
         try {
             ExecutionContext ec = new ExecutionContext();
             // Bridge with old XWiki Context, required for old code.
             ec.setProperty("xwikicontext", context);
             ecim.initialize(ec);
             execution.setContext(ec);
 So ininitalize() is only called once and always with xwikiContext set.
 To resume, it uses the first request generated XWikiContext to create
 an XWikiContext independent form the request and use it to generate
 default XWikiContext for thread not generated by the application
 server when theses are initializing ExecutionContext.
 WDYT ? 
 How do you pass the newly created XWikiContext to the Object in the
 thread that needs to use it? Are you overwriting the XWikiContext in
 the EC? 
 
"when ExecutionContextInitializer is called with a ExecutionContext
which does not contains any XWikiContext a clone of the stub
XWikiContext is injected in the Execution context."
The XWikiStubContextInitializer has two role:
- catch the first valid XWikicontext
- inject a stub XWikiContext in ExecutionContext when it does not
already contains a valid one
 From that there is several choices: 
- make sure
the different ExecutionContextInitializer implementations
does not fail when there is no XWikiContext already in the
ExecutionContext
- implements some priority support to ExeutionContextInitializer
Doing this way means that component initializing ExecutionContext for
it's deamon thread does not even have to know about XWikiContext.
 Do you plan to refactor current daemon threads to use this new way of
 doing things?
 Sounds ok to me for now.
 Thanks
 -Vincent
 _______________________________________________
 devs mailing list
 devs(a)xwiki.org
 
http://lists.xwiki.org/mailman/listinfo/devs
 
--
Thomas Mortagne