On Jan 4, 2009, at 11:03 AM, Markus KARG wrote:
> Paul,
>
> when developing the WebDAV contribution for Jersey, I noticed two
> aspects which are rather sad for the programmer. I don't know a good
> solution, so I wanted to discuss this with you: WebDAV Headers and
> WebDAV Status Codes.
>
> WebDAV adds more HTTP headers and status codes which are often used
> in a lots of places. So it would be great if the programmer doesn't
> see a difference in HTTP headers and codes and WebDAV headers and
> acodes support. Unfortunately this seems to be impossible: The
> support for HTTP status codes in Jersey is basing on Response.Status
> which is an enum and as such cannot get extended. But other classes
> expect exactly that enum as a paramter (or will return it). This
> cannot get extended in any way! Same for headers: Those are defined
> in an Interface using abstract methods, so I do not see any chance
> to convince the actual implementation classes to process any WebDAV
> headers (without changing the core of Jersey).
>
and JAX-RS. I think there is a fundamental constraint with enum that
makes this difficult to do anything about it.
> Second, I did not find a way to configure the ResponseBuilder
> factory to return an instance of "WebDAVResponseBuilder" which would
> be able to provide factory methods for adding the WebDAV folders in
> the same smart way like "lastModified()" or "expires()" would do for
> HTTP.
I cannot see any solution except creating your own builder that
internally uses Response.ResponseBuilder from which you can get an
instance of Response. The build method could return an instance of
Response. You can duplicate the methods on ResponseBuilder, except
that they would return your own builder instance.
>
> So my question is: Since JAX-RS is not targeting solely on HTTP, how
> is this thought to be extended by e. g. WebDAV?
>
> I don't like the idea to change the core of Jersey to support
> WebDAV. So it would be great if there would be support for this
> extensibility in a future JAX-RS specification.
>
The best i can suggest in this respect is to log issues against the
JAX-RS API.
Paul.