sequence of creation during move

["Pill, Juergen" <Ju...@softwareag.com>]

Hello,

During a TaminoContentStore.storeRevisionContent we modify the associated
descriptor and store the descriptor in the associated store.
During a move command we get an Exception that the associated descriptor
does not exist. (We had a similar problem before in the create command,
which was fixed in that way, that we rely now, that the descriptor is stored
to the associate store after the content was stored).

Can we rely on this fact in the storeRevisionContent method as well, e.g.
the TaminoContentStore does not send the changes to the
TaminoDescriptorStore directly, but the higher level will do this. (This is
already true for the move method (in our environment)).

Best regards

Juergen Pill


PS:

To my understanding the WebDav client package is an API for the WebDav
protocol and can talk to every WebDav server (not only Slide). The class
org.apache.webdav.lib.WebdavClient does the shipping of the WebDav protocol.
This is done on a socket base. Is there a reason why the classes java.net.*
(e.g. HttpURLConnection) aren't used for this. Would this make life simpler?
(the DavExplorer uses 



a HttpClient package, which is (unfortunately under GNU license)).

Re: sequence of creation during move

[Remy Maucherat <re...@apache.org>]

> Hello,
>
> During a TaminoContentStore.storeRevisionContent we modify the associated
> descriptor and store the descriptor in the associated store.
> During a move command we get an Exception that the associated descriptor
> does not exist. (We had a similar problem before in the create command,
> which was fixed in that way, that we rely now, that the descriptor is
stored
> to the associate store after the content was stored).

Is it when using Macro.copy ?
Can I get a stack trace ?

> Can we rely on this fact in the storeRevisionContent method as well, e.g.
> the TaminoContentStore does not send the changes to the
> TaminoDescriptorStore directly, but the higher level will do this. (This
is
> already true for the move method (in our environment)).

Yes (but could you send me the fix you applied to check if I missed
something ?).

> PS:
>
> To my understanding the WebDav client package is an API for the WebDav
> protocol and can talk to every WebDav server (not only Slide).

Yes. However, the plan is to have it mirror on the client side the DAV
functionality of the DAV servlet. So when I add DAV ACL in the DAV servlet,
I want to have a client which supports DAV ACL (and so on for Delta V /
DASL).

> The class
> org.apache.webdav.lib.WebdavClient does the shipping of the WebDav
protocol.
> This is done on a socket base. Is there a reason why the classes
java.net.*
> (e.g. HttpURLConnection) aren't used for this. Would this make life
simpler?

HttpURLConnection doesn't support everything in HTTP/1.1, doesn't support
digest auth (the Slide client doesn't support it yet either, but will in the
future), etc ...

> (the DavExplorer uses a HttpClient package, which is (unfortunately under
GNU
> license)).

I wouldn't have used it even if it was an Apache project, as it's not
designed to be extensible (read : add new HTTP methods - or change the
behavior of existing ones -, like WebDAV does).

Remy