jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fried <dfr...@phoenix-int.com>
Subject Re: Result of VERSION-CONTROL request
Date Wed, 29 Oct 2008 21:06:12 GMT
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.


View raw message