[xwiki-devs] ContextPath null inside job / document saving ?
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
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). 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. 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
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 ?
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
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.
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
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 ... 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
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
Le 1 oct. 2013 10:54, "Thomas Mortagne" <[email protected]> a écrit :
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.
Sorry I don't get it... Just above you said to not use XWiki#getXWiki which is in com.com.xwiki. I always thought com.xpn.xwiki.api to form xwiki (old) core api. These classes are what was published in your javadoc since the beginning almost. Then again, what api should I use to manipulate pages/objects from java ?
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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Tue, Oct 1, 2013 at 11:15 AM, Jeremie BOUSQUET <[email protected]> wrote:
Le 1 oct. 2013 10:54, "Thomas Mortagne" <[email protected]> a écrit :
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.
Sorry I don't get it... Just above you said to not use XWiki#getXWiki which is in com.com.xwiki.
You are mixing two very different things here: * you should not get the XWiki object using com.xpn.xwiki.XWiki#getXWiki not matter what API you are using to manipulate documents. This method is used at a low level to initialize the context of a request. When you need the XWiki object, get it from the XWikiContext object (XWikiContext#getWiki()). * when you are in Java, using com.xpn.xwiki.api classes is counter productive
I always thought com.xpn.xwiki.api to form xwiki (old) core api.
These are scripting API full of Velocity helpers and automatic right checking that you usually don't care about when you are in Java or that you checked yourself already before manipulating the documents. You could see com.xpn.xwiki.api as an ancestor of a ScriptService for the model.
These classes are what was published in your javadoc since the beginning almost.
Yes and that was an error.
Then again, what api should I use to manipulate pages/objects from java ?
Your entry point for manipulating the model in Java is XWikiContext, usually the easiest being the access it with the XWikiContext provider. Then you get everything else from it: * xcontext.getWiki() * xcontext.getWiki().getDocument(...) * xcontext.getWiki().getDocument().getXObject(...) * ...
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 _______________________________________________ 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
2013/10/1 Thomas Mortagne <[email protected]>
On Tue, Oct 1, 2013 at 11:15 AM, Jeremie BOUSQUET <[email protected]> wrote:
Le 1 oct. 2013 10:54, "Thomas Mortagne" <[email protected]> a écrit :
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.
Sorry I don't get it... Just above you said to not use XWiki#getXWiki which is in com.com.xwiki.
You are mixing two very different things here: * you should not get the XWiki object using com.xpn.xwiki.XWiki#getXWiki not matter what API you are using to manipulate documents. This method is used at a low level to initialize the context of a request. When you need the XWiki object, get it from the XWikiContext object (XWikiContext#getWiki()).
I always thought com.xpn.xwiki.api to form xwiki (old) core api.
These are scripting API full of Velocity helpers and automatic right checking that you usually don't care about when you are in Java or that you checked yourself already before manipulating the documents. You could see com.xpn.xwiki.api as an ancestor of a ScriptService for the model.
These classes are what was published in your javadoc since the beginning almost.
Yes and that was an error.
Then again, what api should I use to manipulate pages/objects from java ?
Your entry point for manipulating the model in Java is XWikiContext, usually the easiest being the access it with the XWikiContext provider.
Then you get everything else from it: * xcontext.getWiki() * xcontext.getWiki().getDocument(...) * xcontext.getWiki().getDocument().getXObject(...) * ...
Wow ok, sorry for that ... I finally got it :-) In my mind I mixed getWiki() and getXWiki(), and I didn't realize that in my code when I did xwiki.getXWiki(), I was calling it on com.xpn.xwiki.XWiki - I thought I was in api.XWiki. You're absolutely right of course, and I never intended to call this getXWiki() method in fact. That's a crappy part that remained when I quickly translated all this from groovy I think ... Because on another parts I do exactly what you show (ie, use xcontext.getWiki()). Many thanks for your patience ! :) Jeremie
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 _______________________________________________ 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
participants (2)
-
Jeremie BOUSQUET -
Thomas Mortagne