Result of VERSION-CONTROL request

The WebDAV standard seems to indicate that the result of a VERSION-CONTROL
request should be a resource which is in the checked-in state:

"If the request-URL identified a
versionable resource at the time of the request, the request MUST
have created a new version history and MUST have created a new
version resource in that version history. The resource MUST have
a DAV:checked-in property that identifies the new version."

But Jackrabbit's WebDAV implementation seems to leave the resource in the
checked-out state. This probably isn't a problem in most cases, since the
VERSION-CONTROL request, when applied to an already version-controlled
resource, is not guaranteed to leave the resource in a checked-in state, so
applications will have to handle this anyway. But it seems like an
arbitrary departure from the standard.

Two questions:
* is this ever a problem in practice? (in other words, should I care?)
* is there an easy way to add the version-controlled JCR mixin to the
resource and check it in atomically, all in one fell swoop, as part of the
version-control handler?

For example, in VersionControlledResourceImpl::addVersionControl() , would
the following code work?

if (!isVersionControlled()) {
Node item = getNode();
try {
item.addMixin(JcrConstants.MIX_VERSIONABLE);
item.save();
item.checkin(); // <<<====== ADDED LINE OF CODE
} catch (RepositoryException e) {
throw new JcrDavException(e);
}
}

Should checkin() come before save()? I am not so familiar with how JCR
works yet.

Thanks in advance!

--Dave
--
View this message in context: http://www.nabble.com/Result-of-VERS...p20209013.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.

Dave Fried wrote:
> The WebDAV standard seems to indicate that the result of a VERSION-CONTROL
> request should be a resource which is in the checked-in state:
>
> "If the request-URL identified a
> versionable resource at the time of the request, the request MUST
> have created a new version history and MUST have created a new
> version resource in that version history. The resource MUST have
> a DAV:checked-in property that identifies the new version."
>
> But Jackrabbit's WebDAV implementation seems to leave the resource in the
> checked-out state. This probably isn't a problem in most cases, since the
> VERSION-CONTROL request, when applied to an already version-controlled
> resource, is not guaranteed to leave the resource in a checked-in state, so
> applications will have to handle this anyway. But it seems like an
> arbitrary departure from the standard.
>
> Two questions:
> * is this ever a problem in practice? (in other words, should I care?)

I can imagine it can be a problem that rely on the semantics.

> * is there an easy way to add the version-controlled JCR mixin to the
> resource and check it in atomically, all in one fell swoop, as part of the
> version-control handler?
>
> For example, in VersionControlledResourceImpl::addVersionControl() , would
> the following code work?
>
> if (!isVersionControlled()) {
> Node item = getNode();
> try {
> item.addMixin(JcrConstants.MIX_VERSIONABLE);
> item.save();
> item.checkin(); // <<<====== ADDED LINE OF CODE
> } catch (RepositoryException e) {
> throw new JcrDavException(e);
> }
> }
>
> Should checkin() come before save()? I am not so familiar with how JCR
> works yet.

I think moving it up wouldn't work, as the addMixin request wouldn't
have been executed yet.

BR, Julian

This is an old discussion in this list In my application I had to perform
a checkin after adding a new file. And the same issue in present WebDAV.
Well, Jackrabbit in very generic and you have to adapt it to your needs...
and this seems ti be an example of it.

On Tue, Oct 28, 2008 at 4:22 PM, Dave Fried <dfried@phoenix-int.com> wrote:

>
> The WebDAV standard seems to indicate that the result of a VERSION-CONTROL
> request should be a resource which is in the checked-in state:
>
> "If the request-URL identified a
> versionable resource at the time of the request, the request MUST
> have created a new version history and MUST have created a new
> version resource in that version history. The resource MUST have
> a DAV:checked-in property that identifies the new version."
>
> But Jackrabbit's WebDAV implementation seems to leave the resource in the
> checked-out state. This probably isn't a problem in most cases, since the
> VERSION-CONTROL request, when applied to an already version-controlled
> resource, is not guaranteed to leave the resource in a checked-in state, so
> applications will have to handle this anyway. But it seems like an
> arbitrary departure from the standard.
>
> Two questions:
> * is this ever a problem in practice? (in other words, should I care?)
> * is there an easy way to add the version-controlled JCR mixin to the
> resource and check it in atomically, all in one fell swoop, as part of the
> version-control handler?
>
> For example, in VersionControlledResourceImpl::addVersionControl() , would
> the following code work?
>
> if (!isVersionControlled()) {
> Node item = getNode();
> try {
> item.addMixin(JcrConstants.MIX_VERSIONABLE);
> item.save();
> item.checkin(); // <<<====== ADDED LINE OF CODE
> } catch (RepositoryException e) {
> throw new JcrDavException(e);
> }
> }
>
> Should checkin() come before save()? I am not so familiar with how JCR
> works yet.
>
> Thanks in advance!
>
> --Dave
> --
> View this message in context:
> http://www.nabble.com/Result-of-VERS...p20209013.html
> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>
>


--
Paco Avila
GIT Consultors
tel: +34 971 498310
fax: +34 971496189
e-mail: pavila@git.es
http://www.git.es

hi dave

> The WebDAV standard seems to indicate that the result of a VERSION-CONTROL
> request should be a resource which is in the checked-in state:
>
> "If the request-URL identified a
> versionable resource at the time of the request, the request MUST
> have created a new version history and MUST have created a new
> version resource in that version history. The resource MUST have
> a DAV:checked-in property that identifies the new version."

> But Jackrabbit's WebDAV implementation seems to leave the resource in the
> checked-out state.

as far as i know that is the default behaviour defined in JSR 170 if a
node is made mix:versionable.
see section "8.2.4 Initializing the Version History".

if this turns out to be a problem with dav clients, we should add
the line you suggest.

the only drawback of the additional checkin would be, that this
creates an extra version in the repository without necessitiy (and
without having made any changes).

so: it doesn't "create a new version resource in that v-history"
but two of them: the root version and the subsequent v1. this
doesn't look inituitive to me...

but i don't have any strong feelings about the change, if the
current behaviour turns out to be problematic. in this case you
may open an issue in jira.

thanks & regards
angela

Angela Schreiber wrote:
> ...
> as far as i know that is the default behaviour defined in JSR 170 if a
> node is made mix:versionable.
> see section "8.2.4 Initializing the Version History".
>
> if this turns out to be a problem with dav clients, we should add
> the line you suggest.
>
> the only drawback of the additional checkin would be, that this
> creates an extra version in the repository without necessitiy (and
> without having made any changes).
> ...

I would call that an advantage :-)

After all, if you don't want the current state of the resource to become
the first version, then you can do the edits first and then invoke
VERSION-CONTROL.

> so: it doesn't "create a new version resource in that v-history"
> but two of them: the root version and the subsequent v1. this
> doesn't look inituitive to me...

Well, it's what the spec requires. And yes, it's unfortunate that
RFC3253 and JSR170 -- given the same author for this part :-) -- require
opposite behaviours.

> but i don't have any strong feelings about the change, if the
> current behaviour turns out to be problematic. in this case you
> may open an issue in jira.

I'd be in favor to change it without an actual bug report. Problems like
these can be hard to debug.

What we need is a WebDAV test case...

BR, Julian

hi julian

> I'd be in favor to change it without an actual bug report.

why? i prefer to have issues attached to modifications
made in the source in order to be able to track
changes and mention the changes in the release notes.

> What we need is a WebDAV test case...

in addition. but not instead of a jira issue.

regards
angela

Angela Schreiber wrote:
> hi julian
>
>> I'd be in favor to change it without an actual bug report.
>
> why? i prefer to have issues attached to modifications
> made in the source in order to be able to track
> changes and mention the changes in the release notes.

Of course.

I meant "bug report" the the sense of a problem being reported. So yes,
a JIRA issue should be opened.

>> What we need is a WebDAV test case...
>
> in addition. but not instead of a jira issue.

Of course not.

Sorry for the confusion.

BR, Julian

Julian Reschke wrote:
> Angela Schreiber wrote:
>> but i don't have any strong feelings about the change, if the
>> current behaviour turns out to be problematic. in this case you
>> may open an issue in jira.
>
> I'd be in favor to change it without an actual bug report. Problems
> like these can be hard to debug.
>
> What we need is a WebDAV test case...

Right now, I'm actually using a unit test package from a commercial
developer which has its own WebDAV client and server implementations
(the server is unfortunately not cross-platform; hence Jackrabbit).
There are a number of areas of non-compliance I've found in the server
as it stands (or rather stood the last time I downloaded the source).
While I am embroiled in work that makes it difficult to contribute to
the Jackrabbit project directly, I may at some point near in the future
submit issues on some of the various problems that I've come across and
perhaps suggest fixes.

For example, there are a number of cases where Jackrabbit's WebDAV
implementation does not return the correct status code. The server
almost /never/ properly reports which precondition failed, which is
something quite useful for debugging. I've extended the DavException
class to send XML error status back with preconditions (when I come
across situations where this might be useful to the client), and this is
probably a very useful general technique.* Also, it's necessary in many
places to catch different subclasses of the RepositoryException to
determine what type of error actually occurred, rather than just tossing
back an IOException, which is useless to the client.

The other egregious issues are with handling of lock tokens, which
really should be their own class and not just a string. That way, the
class would be smart enough to strip the "opaquelocktoken:" prefix /all
the time/ before doing comparisons, leading to far less cases where the
system is trying to do a straight-up string compare between one token
with the prefix and one without (this happened in a disappointing number
of places in the Dav server code).

Oh, and one more which was a serious problem for me today... handling of
XML files is wrong. Uploading a file with MIME type "text/xml" results
in an unstructured JCR node rather than a file node, which does not
follow WebDAV semantics; when operating as a WebDAV server, Jackrabbit
should always treat uploaded files as files. The only straightforward
solution I could find was changing config.xml to remove the XmlHandler
from upload processing.

Okay, I'm done ranting. Overall, Jackrabbit is actually an
excellent and well-structured software project and I'm really glad to be
working with it instead of Slide. There are just some kinks that need
to be worked out.

*As an aside, I think the server should almost never return a 500 error
when possible, and always return XML with missed preconditions on an
error. 500 should be reserved for cases where there actually is an
internal server error that prevents the request from being processed.

--Dave

hi dave

thanks for the feedback.
can you open jira issues for the things you think are
wrong or need improvement? that's easier to handle in
the first place. in addition there is a least a chance
that the issues get adressed

> Oh, and one more which was a serious problem for me today... handling of
> XML files is wrong. Uploading a file with MIME type "text/xml" results
> in an unstructured JCR node rather than a file node,

really? as far as i know it creates an nt:file node, underneith
a jcr:content node and then extracts the xml below that node.

> The only straightforward
> solution I could find was changing config.xml to remove the XmlHandler
> from upload processing.

that's what i would have suggested to you.
maybe you want to remove the ZipHandler as well, because
it works similarly and extracts the zip content.

regards
angela

Angela Schreiber wrote:
>
> hi dave
>
> thanks for the feedback.
> can you open jira issues for the things you think are
> wrong or need improvement? that's easier to handle in
> the first place. in addition there is a least a chance
> that the issues get adressed
>

Like I said before, I will almost certainly do this when I have the time.
The nice thing about posting this stuff is that it gives me a record (other
than my own diff logs and TODO lists, anyway) to actually create the bug
items.



>> Oh, and one more which was a serious problem for me today... handling of
>> XML files is wrong. Uploading a file with MIME type "text/xml" results
>> in an unstructured JCR node rather than a file node,
>
> really? as far as i know it creates an nt:file node, underneith
> a jcr:content node and then extracts the xml below that node.
>

Not in the version I have. I suppose that modifying the XmlHandler to
actually do this could be another workaround. It's also possible this was
an issue that was fixed in the few weeks since I got source.



>> The only straightforward
>> solution I could find was changing config.xml to remove the XmlHandler
>> from upload processing.
>
> that's what i would have suggested to you.
> maybe you want to remove the ZipHandler as well, because
> it works similarly and extracts the zip content.
>

Was thinking about that, too. Thanks for the confirmation of my suspicion.


The default inclusion of special content handlers, especially when they're
used by the default implementation of the WebDAV servlet, feels wrong to me.
The basic behavior, for instance, of uploading a .zip file should be that
the zip file gets uploaded to the server. It's an easy way to store and
retrieve data, especially when speed or bandwidth is an issue.

Being able to automatically unpack compressed files is nice, but seems like
an optional feature rather than something that should be on by default -
especially if it means the file is going to "look" different on the server
than it did on your local drive. Just my $0.02.

--Dave
--
View this message in context: http://www.nabble.com/Result-of-VERS...p20252409.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.