[xwiki-devs] [VOTE] Generic stub XWikiContext provider and initializer
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 containing a XWikiContext it call XWikiStubContextProvider.initialize to create a XWiki context independent from the request but still containing scheme/host/port information 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. 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 ? -- Thomas Mortagne
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
On Mon, Aug 10, 2009 at 10:06, Vincent Massol<[email protected]> 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 > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > -- Thomas Mortagne
participants (2)
-
Thomas Mortagne -
Vincent Massol