- xwiki-devs@xwiki.org - lists.xwiki.org

Re: [xwiki-devs] Blog Wiki 2.0 Upgrade 7th Draft
by Andreas Schaefer 10 Aug '09

10 Aug '09

Hi Marius >>> Collections.EMPTY_MAP is used to fill a "missing" parameter when a >>> method is overloaded. Use the signature that specifies the parameter: >>> >>> public SyndEntrySourceApi getSyndEntryArticleSource() >>> public SyndEntrySourceApi getSyndEntryArticleSource(Map params) >> > >> I noticed that but the problem is that later these maps are used to > >Used where? In your code or in the feed plug-in code? I doubt it's in >the feed plug-in code because the semantic I choose was: if you don't >specify any parameters then you don't have any parameters and thus >there's no need to change the map. If you want to specify parameters >then you have to provide at least an empty (mutable) map. > >Can you give me a code snipped that shows the failure? Calling getBlogFeed(String,int,int): public SyndFeed getBlogFeed(String query, int count, int start) { return getBlogFeed(query, count, start, Collections.EMPTY_MAP); } Call THIS: public SyndFeed getBlogFeed(String query, int count, int start, Map metadata) { if (query == null) { XWikiRequest request = getXWikiContext().getRequest(); String category = request.getParameter("category"); if (category == null || category.equals("")) { query = ", BaseObject as obj where obj.name=doc.fullName and obj.className='XWiki.ArticleClass' and obj.name<>'XWiki.ArticleClassTemplate' order by doc.creationDate desc"; } else { query = ", BaseObject as obj, DBStringListProperty as prop join prop.list list where obj.name=doc.fullName and obj.className='XWiki.ArticleClass' and obj.name<>'XWiki.ArticleClassTemplate' and obj.id=prop.id.id and prop.id.name='category' and list = '" + category + "' order by doc.creationDate desc"; } } SyndFeed blogFeed = getArticleFeed(query, count, start, fillBlogFeedMetadata(metadata)); if (blogFeed != null) { blogFeed.setImage(getDefaultFeedImage()); } return blogFeed; } which calls THIS: private Map fillWebFeedMetadata(Map metadata) { fillDefaultFeedMetadata(metadata); // these strings should be taken from a resource bundle String title = "Feed for document changes"; String description = title; if (!keyHasValue(metadata, "title", "")) { metadata.put("title", title); } if (!keyHasValue(metadata, "description", "")) { metadata.put("description", description); } return metadata; } which calls THIS where it fails because the MAP is immutable: private Map fillDefaultFeedMetadata(Map metadata) { XWiki xwiki = getXWikiContext().getWiki(); XWikiDocument doc = getXWikiContext().getDoc(); if (metadata.get("author") == null) { metadata.put("author", xwiki.getUserName(doc.getAuthor(), null, false, getXWikiContext())); } if (!keyHasValue(metadata, "copyright", "")) { metadata.put("copyright", xwiki.getWebCopyright(getXWikiContext())); } if (!keyHasValue(metadata, "encoding", "")) { metadata.put("encoding", xwiki.getEncoding()); } if (!keyHasValue(metadata, "url", "")) { metadata.put("url", "http://" + getXWikiContext().getRequest().getServerName()); } if (!keyHasValue(metadata, "language", "")) { metadata.put("language", doc.getDefaultLanguage()); } return metadata; } >> The FeedPlugin has two problems. A default query is not working >> because it looks for XWiki.ArticleClass which I changed but also it >> uses the XWiki.ArticleClass to define the properties to read out the >> values and that fails with a NPE: Here is where XWiki.ArticleClass is used: public SyndFeed getBlogFeed(String query, int count, int start, Map metadata) { if (query == null) { XWikiRequest request = getXWikiContext().getRequest(); String category = request.getParameter("category"); if (category == null || category.equals("")) { query = ", BaseObject as obj where obj.name=doc.fullName and obj.className='XWiki.ArticleClass' and obj.name<>'XWiki.ArticleClassTemplate' order by doc.creationDate desc"; } else { query = ", BaseObject as obj, DBStringListProperty as prop join prop.list list where obj.name=doc.fullName and obj.className='XWiki.ArticleClass' and obj.name<>'XWiki.ArticleClassTemplate' and obj.id=prop.id.id and prop.id.name='category' and list = '" + category + "' order by doc.creationDate desc"; } } SyndFeed blogFeed = getArticleFeed(query, count, start, fillBlogFeedMetadata(metadata)); if (blogFeed != null) { blogFeed.setImage(getDefaultFeedImage()); } return blogFeed; } >> I had to change the Source >> Parameters in order to make it work. I will have a closer look at the >> Feed Plugin and provide a patch when I could make it work. > >Again, can you provide a code snipped that shows the issue? > >SyndEntryDocumentSource is a generic feed entry source that knows >nothing about XWiki.ArticleClass. It can generate a feed entry by >collecting values from different properties of different objects >attached to the source document. You can even specify velocity >expressions to fill feed entry fields. > >Feed plug-in provides some helper methods for generating a feed from >XWiki.ArticleClass objects. Forget about it. For the new blog you have >to use the generic API and specify the mapping between feed entry fields >and Blog.BlogPostClass properties. Take a closer look at my example >http://tinyurl.com/cps7oa . As you can see I map: > >* ContentLength field -> a constant, 10 >* title field -> document title >* description field -> the content property of the first >XWiki.ArticleClass object attached to the source document >* publishedDate -> the date property of the XWiki.ArticleClass object >with index 0 among all the XWiki.ArticleClass objects attached to the >source document >* updatedDate -> a velocity expression, $doc.date.time >* categories -> a list: $doc.space, $doc.name, $doc.isNew() > >So what stops you from mapping feed entry fields to Blog.BlogPostClass >properties ? If we have methods that provide default values shouldn't it then work. The SyndEntryDocumentSource uses the XWiki.ArticleClass as the default mapping for the properties and it fails silently if the properties cannot be found. Shouldn't we then provide a default mapping for getBlogFeed() methods that don't have one? I will use the code snipped you mentioned above and see if I can make it work with 2.0m2 when it comes out. Thanks - Andy

1 0

[xwiki-devs] Blog Wiki 2.0 Upgrade 7th Draft
by Andreas Schaefer 10 Aug '09

10 Aug '09

Hi I just attached the 7th draft of the Blog 2.0 Wiki Syntax upgrade to this JIRA report: http://jira.xwiki.org/jira/browse/XABLOG-50 This one includes the upgrades of the Panels to the 2.0 syntax. The only thing remaining are the RSS feeds and these cannot be upgraded now because the XHTML renderer does add the macro content as comment to the top of the output AHEAD of the <?xml> which is not allowed by the XML specification. So far I could not find a way to suppress that. I tried to create a XML renderer macro but got nowhere with it. My own Blog: http://madplanet.com/xwiki/bin/view/Blog/ uses the latest (7th) draft of the blog upgrade. Cheers Andreas Schaefer CEO of Madplanet.com Inc. EMail: andreas.schaefer(a)madplanet.com schaefera(a)me.com Twitter: andy_mpc AIM: schaefera(a)me.com

5 14

[xwiki-devs] [VOTE] Add macro name in the Macro descriptor
by Vincent Massol 10 Aug '09

10 Aug '09

Hi, Right now we have a macro description in the macro descriptor but we're missing the macro name (ie a human understandable name to be used when displaying the list of macros in the wysiwyg editor for example). So I'm proposing we: * rename getMacroNames* methods in MacroManager/MacroCategoryManagers to getMacroIds * add a getName() in MacroDesciptor Here's my +1 Thanks -Vincent

5 4

Re: [xwiki-devs] [xwiki-notifications] r22458 - in platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-equation/src/test: java/org/xwiki/rendering resources
by Vincent Massol 10 Aug '09

10 Aug '09

On Aug 10, 2009, at 11:41 AM, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2009-08-10 11:41:27 +0200 (Mon, 10 Aug 2009) > New Revision: 22458 > > Added: > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-equation/src/test/resources/macroequation1.test > Removed: > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-equation/src/test/resources/macromessage1.test > Modified: > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-equation/src/test/java/org/xwiki/rendering/ > RenderingTests.java > Log: > XWIKI-4139: New {{equation}} macro for displaying mathematical > expressions > Adding a simple test > > Modified: platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/ > xwiki-rendering-macro-equation/src/test/java/org/xwiki/rendering/ > RenderingTests.java > =================================================================== > --- platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-equation/src/test/java/org/xwiki/rendering/ > RenderingTests.java 2009-08-10 09:03:24 UTC (rev 22457) > +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-equation/src/test/java/org/xwiki/rendering/ > RenderingTests.java 2009-08-10 09:41:27 UTC (rev 22458) > @@ -45,7 +45,7 @@ > { > RenderingTestSuite suite = new RenderingTestSuite("Test > Equation Macro"); > > - suite.addTestsFromResource("macromessage1", true); > + suite.addTestsFromResource("macroequation1", true); > > ComponentManagerTestSetup testSetup = new > ComponentManagerTestSetup(suite); > setUpMocks(testSetup.getComponentManager()); > @@ -80,16 +80,16 @@ > context.checking(new Expectations() > { > { > - oneOf(mockDocumentAccessBridge).getURL(null, "tex", > null, null); > + > atLeast(2).of(mockDocumentAccessBridge).getURL(null, "tex", null, > null); are 2 calls really part of the contract? If you don't need to test the number of calls you should use allow(). -Vincent > will(returnValue("/xwiki/bin/view/Main/")); > > - oneOf(mockConfiguration).getRenderer(); > + atLeast(2).of(mockConfiguration).getRenderer(); > will(returnValue("snuggletex")); > > - oneOf(mockImageStorage).get(with(any(String.class))); > - will(returnValue(false)); > + > atLeast(2).of(mockImageStorage).get(with(any(String.class))); > + will(returnValue(null)); > > - > oneOf(mockImageStorage).put(with(any(String.class)), > with(any(ImageData.class))); > + > atLeast(2).of(mockImageStorage).put(with(any(String.class)), > with(any(ImageData.class))); > } > }); > } > > Copied: platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/ > xwiki-rendering-macro-equation/src/test/resources/ > macroequation1.test (from rev 22456, platform/core/trunk/xwiki- > rendering/xwiki-rendering-macros/xwiki-rendering-macro-equation/src/ > test/resources/macromessage1.test) > =================================================================== > --- platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-equation/src/test/resources/ > macroequation1.test (rev 0) > +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-equation/src/test/resources/macroequation1.test > 2009-08-10 09:41:27 UTC (rev 22458) > @@ -0,0 +1,18 @@ > +.#----------------------------------------------------- > +.input|xwiki/2.0 > +.#----------------------------------------------------- > +{{equation}}a+b{{/equation}} > +.#----------------------------------------------------- > +.expect|event/1.0 > +.#----------------------------------------------------- > +beginDocument > +beginMacroMarkerStandalone [equation] [] [a+b] > +beginParagraph > +onImage: [/xwiki/bin/view/Main// > 06fbba0acf130efd9e147fdfe91a943cc4f3e29972c6cd1d972e9aabf0900966] > [false] [[alt]=[a+b]] > +endParagraph > +endMacroMarkerStandalone [equation] [] [a+b] > +endDocument > +.#----------------------------------------------------- > +.expect|xwiki/2.0 > +.#----------------------------------------------------- > +{{equation}}a+b{{/equation}} > > Deleted: platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/ > xwiki-rendering-macro-equation/src/test/resources/macromessage1.test > =================================================================== > --- platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-equation/src/test/resources/macromessage1.test > 2009-08-10 09:03:24 UTC (rev 22457) > +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-equation/src/test/resources/macromessage1.test > 2009-08-10 09:41:27 UTC (rev 22458) > @@ -1,17 +0,0 @@ > -.#----------------------------------------------------- > -.input|xwiki/2.0 > -.#----------------------------------------------------- > -{{equation}}a+b{{/equation}} > -.#----------------------------------------------------- > -.expect|event/1.0 > -.#----------------------------------------------------- > -beginDocument > -beginMacroMarkerStandalone [equation] [] [a+b] > -beginParagraph > -endParagraph > -endMacroMarkerStandalone [equation] [] [a+b] > -endDocument > -.#----------------------------------------------------- > -.expect|xwiki/2.0 > -.#----------------------------------------------------- > -{{equation}}a+b{{/equation}}

2 1

Re: [xwiki-devs] [xwiki-notifications] r22449 - in platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src: main/java/org/xwiki/rendering/internal/macro test/java/org/xwiki/rendering/internal/macro
by Vincent Massol 10 Aug '09

10 Aug '09

On Aug 9, 2009, at 9:12 PM, asiri (SVN) wrote: > Author: asiri > Date: 2009-08-09 21:12:30 +0200 (Sun, 09 Aug 2009) > New Revision: 22449 > > Modified: > platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/ > java/org/xwiki/rendering/internal/macro/ > DefaultMacroCategoriesManager.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/test/ > java/org/xwiki/rendering/internal/macro/ > DefaultMacroCategoriesManagerTest.java > Log: > XWIKI-4131: Add support for organizing macros by category > > * getMacroNames() should return only macro names, not macro hints. > * Fixed a NPE possibility. > * Added one more test case. > > Modified: platform/core/trunk/xwiki-rendering/xwiki-rendering-api/ > src/main/java/org/xwiki/rendering/internal/macro/ > DefaultMacroCategoriesManager.java > =================================================================== > --- platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/ > java/org/xwiki/rendering/internal/macro/ > DefaultMacroCategoriesManager.java 2009-08-09 14:04:29 UTC (rev 22448) > +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/ > java/org/xwiki/rendering/internal/macro/ > DefaultMacroCategoriesManager.java 2009-08-09 19:12:30 UTC (rev 22449) > @@ -19,25 +19,25 @@ > */ > package org.xwiki.rendering.internal.macro; > > +import java.util.Collections; > +import java.util.HashMap; > +import java.util.HashSet; > +import java.util.Map; > +import java.util.Properties; > +import java.util.Set; > + > import org.xwiki.component.annotation.Component; > import org.xwiki.component.annotation.Requirement; > import org.xwiki.component.logging.AbstractLogEnabled; > import org.xwiki.component.manager.ComponentLookupException; > import org.xwiki.component.manager.ComponentManager; > +import org.xwiki.rendering.configuration.RenderingConfiguration; > import org.xwiki.rendering.macro.Macro; > import org.xwiki.rendering.macro.MacroCategoriesManager; > import org.xwiki.rendering.macro.MacroLookupException; > import org.xwiki.rendering.macro.MacroManager; > import org.xwiki.rendering.parser.Syntax; > -import org.xwiki.rendering.configuration.RenderingConfiguration; > > -import java.util.Set; > -import java.util.Collections; > -import java.util.Map; > -import java.util.HashMap; > -import java.util.Properties; > -import java.util.HashSet; > - > /** > * Default implementation of {@link MacroCategoriesManager}. > * > @@ -115,7 +115,7 @@ > return true; > } > }).get(category); > - return Collections.unmodifiableSet(macros); > + return (null != macros) ? > Collections.unmodifiableSet(macros) : Collections.<String>emptySet(); > } > > /** > @@ -131,7 +131,7 @@ > return macroManager.exists(macroName, syntax); > } > }).get(category); > - return Collections.unmodifiableSet(macros); > + return (null != macros) ? > Collections.unmodifiableSet(macros) : Collections.<String>emptySet(); > } > > /** > @@ -152,8 +152,21 @@ > > // Loop through all the macros and categorize them. > Properties categories = > this.configuration.getMacroCategories(); > - for (Map.Entry<String, Macro> entry : allMacros.entrySet()) { > - if (matcher.match(entry.getKey())) { > + for (Map.Entry<String, Macro> entry : allMacros.entrySet()) { > + // Extract macro name. > + String [] hintParts = entry.getKey().split("/"); > + String macroName = null; > + if (hintParts.length > 0) { > + macroName = hintParts[0]; > + } else { > + // Question: Will we ever reach this code? > + getLogger().warn("Invalid macro hint : [" + > entry.getKey() + "]"); > + // Skip this macro. > + continue; > + } This can be improved by sharing code with the MacroManager, by creating some kind of macro syntax parser or factory. Another solution is to rethink they way we register a macro for a given syntax. [snip] Thanks -Vincent

1 1

[xwiki-devs] Wiki Macro Bridge on 2.0M2 for Groovy (was Re: Macros and JavaScript working together (was Re: [DISCUSSION] XWiki Chart Api & Chart Macro))
by Niels Mayer 10 Aug '09

10 Aug '09

On Tue, Aug 4, 2009 at 9:29 AM, Asiri Rathnayake <asiri.rathnayake(a)gmail.com > wrote: > > The wiki macro bridge has been released with 2.0M2. ... > > If you come across any problems while you are at it, we can improve wiki > macro bridge :) > Thanks for reminding me about the Xwiki macro bridge. Looks great and is a big improvement over how things were done previously. Your message was timely as helped me answer one of my big questions about having groovy or clojure macros available on virtual-wiki setup: http://platform.xwiki.org/xwiki/bin/view/DevGuide/WikiMacroTutorial - Wiki macro authors need to have programming rights - Wiki macros can only be defined inside the main wiki, though they can be used throughout a farm I wrote my first macro-bridge macro (see attachment Main.TestMacroBridge.xar ) in groovy in preparation for my experiments with scripting in Clojure. The hardest thing was finding out that the name of "context" had changed to "xcontext" for groovy and other JSR-223 languages, whereas velocity (and WikiMacroTutorial) uses "context". This has been discussed on the lists ( http://markmail.org/message/o2trzrnv5xts6x6v ), and the WikiMacroTutorial needs updating to reflect the final status & naming-conventions. My macro is quite simple. but does a lot, taken from here: http://www.ibm.com/developerworks/java/library/j-pg05199/index.html Usage: {{weather_by_zip zip=92625 /}} Code: ............................... Objects of type XWiki.WikiMacroClass WikiMacroClass 0: weather_by_zip {{script language=groovy}} def rss = new XmlSlurper().parseText((" http://weather.yahooapis.com/forecastrss?p=" + xcontext.macro.params.zip).toURL().text) println rss.channel.title println "Sunrise: ${rss.channel.astronomy.@sunrise}" println "Sunset: ${rss.channel.astronomy.@sunset}" println "Currently:" println "\t" + rss.channel.item.condition.@date println "\t" + rss.channel.item.condition.@temp println "\t" + rss.channel.item.condition.@text {{/script}} Objects of type XWiki.WikiMacroParameterClass WikiMacroParameterClass 0: zip ............................... May be you can put it to test by trying to implement your chart macro ;) It would be more useful to offer all-new Exhibit<http://www.simile-widgets.org/exhibit/> functionality with tighter integration into the Xwiki back-end, e.g. having document/space and other Xwiki "model" information abstractly available to an Exhibit-based "view/controller" to provide a "faceted views" presentation of Xwiki documents and contents. FYI, My existing Exhibit integration with Xwiki demo: http://nielsmayer.com/xwiki/bin/view/Exhibit/Presidents4 (source: http://nielsmayer.com/xwiki/bin/download/Exhibit/Presidents4/Presidents4Pkg…) My main commitment right now is an experiment to see if I can get JSR223-supported Clojure scripting in Xwiki. This message didn't give me much hope of success right now ( http://groups.google.com/group/clojure/msg/ad811b69d448e3db ) but I'll give Clojure on Xwiki a try anyways, and revisit later if it's just a matter of getting more solid JSR223 support for Clojure as development progresses. Niels http://nielsmayer.com

2 5

[xwiki-devs] [VOTE] Use JUnit 4.x and JMock 2.x for all new code
by Vincent Massol 10 Aug '09

10 Aug '09

For an example: http://svn.xwiki.org/svnroot/xwiki/platform/core/trunk/xwiki-observation/sr… If you need to access components you should use AbstractComponentTestCase from shared-tests (instead of AbstractXWikiComponentTestCase which is for JUnit 3.x and JMock 1.x). Here's my +1 Thanks -Vincent

7 6

[xwiki-devs] [VOTE] Remove the TableTraining page from the Sandbox space
by Guillaume Lerouge 10 Aug '09

10 Aug '09

Hi Devs, as described in http://jira.xwiki.org/jira/bro wse/XE-472<http://jira.xwiki.org/jira/browse/XE-472> , I've rewritten the Sandbox space in syntax 2.0. Since operations in table (Sum, multiplication etc...) are not yet supported in XWiki 2.0 syntax, I suggest we remove the Sandbox.TableTraining page for the time being instead of keeping a XWiki 1.0 syntax page in the Sandbox since it doesn't bring much value and cannot be converted satisfactorily as of today. I can't remember any recent email about operations in tables on this list (at least not in the past 2 years), thus I think removing it won't cause too many problems. I'll rewrite it later if / when the new syntax supports such operations once again. Here's my +1 for removing the Sandbox.TableTraining page. Thanks for your feedback, Guillaume -- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/

7 7

[xwiki-devs] [VOTE] API change for Rendering module
by Vincent Massol 10 Aug '09

10 Aug '09

Hi, I'd like to propose the following API changes to the Rendering module: 1) Modify PrintRendererFactory a) There's now one factory component per Renderer type with the following interface: public interface PrintRendererFactory { /** * @return the Syntax supported by the Renderer type * @since 2.0M3 */ Syntax getSyntax(); /** * @param printer the printer to use to output renderer data * @return a new Renderer instance (stateful) * @since 2.0M3 */ PrintRenderer createRenderer(WikiPrinter printer); } b) The getAvailableSynatxes() doesn't exist anymore. It's been moved to SyntaxFactory, see below. 2) Modify SyntaxFactory a) Remove getAvailableSyntaxes() since there are different types of syntaxes: Parser syntaxes, Renderer syntaxes and even amongst Parser/ Renderer there will be different types of them: streaming, block. Thus the new strategy is for client code to directly ask for syntaxes by looking up the objects against the CM. getAvailableSyntaxes() has been deprecated. 3) Introduce BlockRenderer @ComponentRole public interface BlockRenderer { /** * @param block the block to render in the target syntax * @param printer the object where to output the result of the rendering */ void render(Block block, WikiPrinter printer); /** * @param blocks the list of blocks to render in the target syntax * @param printer the object where to output the result of the rendering * @todo remove this API once we introduce the notion of BlockCollection */ void render(Collection<Block> blocks, WikiPrinter printer); } Goals: a) Have 2 types of Renderers (as we'll have 2 types of Parsers in the future): Stream and Block b) reduce code duplication since using the BlockRenderer will simplify the client code 4) Introduce Converter @ComponentRole public interface Converter { void convert(Reader source, Syntax sourceSyntax, Syntax targetSyntax, WikiPrinter printer) throws ConversionException; } Goal: Simplify client code when the need is pure conversion. 5) Move Renderer's implementation classes (components now) in the internal package They're now components and thus we can move them in the internal package. Here's my +1 to all Thanks -Vincent

5 6

[xwiki-devs] [VOTE] Generic stub XWikiContext provider and initializer
by Thomas Mortagne 10 Aug '09

10 Aug '09

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

2 2