Julian Reschke wrote:
> Markus KARG wrote:
>>
>>
>> Craig,
>>
>>
>>
>> thanks for your comments and helping us in this issue. Yes, I share
>> your opinion about the need for a client side WebDAV API, but on the
>> other hand, I actually want to wait with that -- possibly Paul and
>> Marc can be convinced to add JAX-RS client API in JAX-RS 2.0...? :-)
>> ...
>
> Out of curiosity, have you looked at the Apache Jackrabbit WebDAV
> client libraries?
>
I have indeed looked at Jackrabbit's WebDAV client code, and use it in
some applications as well. My only real issue with it is that it
exposes all the complexity of WebDAV at a very low level of granularity
-- you have to be pretty deeply familiar with the WebDAV specs to
understand how to construct request bodies that are meaningful, as well
as interpret the response bodies. In addition to that level of support,
I'd like to have something a bit higher level, along the lines of a call
to get the files in a directory (a PROPFIND of all properties of a
collection, in WebDAV-speak) that gives me back a list of simple
javabeans, one per file, with properties like name, size, creationDate,
and a boolean flag that says whether this is a subdirectory or not.
Making me have to parse a MultiStatusResponse to get that data is cruel
and unusual punishment :-).
An irritant-level concern is that the Jackrabbit client uses Apache
Commons HttpClient for its low level communiciation engine, rather than
java.net.HttpURLConnection. It works, but makes some classes of
debugging HTTP problems (like bad certificates) a little more
complicated to deal with since you have to deal with two stacks instead
of one. Getting Jersey to the point that it could optionally run on
HttpClient as well would make that irritant go away.
Craig
> BR, Julian
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: dev-help_at_jersey.dev.java.net
>