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
