On Tue, Oct 1, 2013 at 10:38 AM, Jeremie BOUSQUET <[email protected]> wrote:
2013/10/1 Thomas Mortagne <[email protected]>
On Tue, Oct 1, 2013 at 10:12 AM, Jeremie BOUSQUET <[email protected]> wrote:
2013/10/1 Thomas Mortagne <[email protected]>
I don't understand why you use XWiki#getXWiki, this method job is to initialize everything related to the request which you usually don't care in a background thread (in as you can see in your case does not work since you don't have an request in that thread).
In fact I use the following to not have update date automatically set when saving document: doc.setContentDirty(false); doc.setMetaDataDirty(false); This is not available from Document but from XWikiDocument, that's why I use XWiki#getXWiki#saveDocument. This is old code. I realize now that maybe I could just update underlying XWikiDocument returned by Document#getDoc, then use Document#saveDocument to save it ?
You should not use api.Document in java. This is a scripting API and to use only in scripts IMO.
You mean this ? http://nexus.xwiki.org/nexus/service/local/repositories/releases/archive/org...
I'm not sure about what else I could use ... I use the Bridge when possible (but it's limited not so better ...), I would use the new model if it was in place and stable. All this code was at start migrated from a Groovy script, so I kept usage of old core for some things. If I understood what you said, this was already discussed here: http://xwiki.markmail.org/message/di3c5hheqhqfgvpe My conclusion was to rely on old core for the time being ...
com.xpn.xwiki.api.Document is an oldcore class too so I don't understand what you mean exactly. Both classes are in the same module but Document is really not well suited for java side and even less for a background thread. All I'm saying here is: don't use com.xpn.xwiki.api classes in Java, I don't see what the bridge has to do with that.
Thanks, Jeremie
A good helper when you need a usable XWikiContext wherether you are in the XWikiContext provider as in:
@Inject Provider<XWikiContext> xcontext;
it gives you the current context in a request thread and one suitable for background thread otherwise.
In fact currently in the component called from my job, I use the
following
to retrieve context and xwiki old-core api, in initialize():
ExecutionContext context = execution.getContext(); this.context = (XWikiContext) context.getProperty("xwikicontext"); this.xwiki = this.context.getWiki();
Only Execution is @Injected. I'll try to get XWikiContext injected as you propose.
Thanks ! Jeremie
On Mon, Sep 30, 2013 at 11:57 PM, Jeremie BOUSQUET <[email protected]> wrote:
Hello,
I'm trying to save a document from inside a job [1] execution, as
follows
roughly:
xwiki.getXWiki(context).saveDocument(doc, comment, context);
Nothing really special ... It used to work (out of a job), but now it throws NPE:
<trace>com.xpn.xwiki.XWiki.stripSegmentFromPath(XWiki.java:4725)</trace>
<trace>com.xpn.xwiki.XWiki.getRequestWikiName(XWiki.java:566)</trace> <trace>com.xpn.xwiki.XWiki.getXWiki(XWiki.java:492)</trace>
<trace>org.xwiki.contrib.mailarchive.internal.persistence.XWikiPersistence.saveAsUser(XWikiPersistence.java:678)</trace>
Checking source code, it happens there (sorry, I roughly decompiled
it):
/* 560 */ if ("1".equals(Param("xwiki.virtual.usepath", "1"))) { /* 561 */ String uri = request.getRequestURI(); /* 562 */ if (LOGGER.isDebugEnabled()) { /* 563 */ LOGGER.debug("Request uri is: " + uri); /* */ } /* */ /* 566 */ uri = stripSegmentFromPath(uri,
request.getContextPath());
From the logs in DEBUG, I see:
"Request uri is: null"
... which is kind of logical I believe, as I'm in a Thread triggered
by
another thread, and not directly in an http request.
I'm not sure of what I should do from here ... And if my analysis is correct, or if something else is wrong. Maybe I should do something with ExecutionContext ...
Thanks,
BR, Jeremie
[1] http://extensions.xwiki.org/xwiki/bin/view/Extension/Job+Module _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne