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/xwiki/platform/xwiki-platform-oldcore/5.1/xwiki-platform-oldcore-5.1-javadoc.jar/!/index.html
>> >
>> > 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
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs

Reply via email to