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.
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?
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?
Do you plan to refactor current daemon threads to use this new way of
doing things?
Sounds ok to me for now.
Thanks
-Vincent