Hi Markus,
As we have discussed before there is not much we can do about status
codes for enums as the "enum" is not extensible so we can never define
an extensible set, and we can never define a complete, because
anything can extend HTTP. So i think we are discussing stuff we cannot
do much about. In hindsight i wish we never provided an enum of status
codes because of such restrictions.
Also Response.ResponseBuilder is not extensible and it is not designed
for ease of use of creating WebDAV specific responses. The solution of
a specific builder, even if there is some duplication, is i think the
best approach and as you indicate in your email on the Fluent API
would be most useful for easily creating WebDAV-based responses.
Paul.
On Jan 25, 2009, at 7:03 PM, Markus KARG wrote:
> WebDAV defines several not HTTP status codes, which currently I have
> covered with my own enum. Unfortunately Response.status() does only
> accept int or JAX-RS Response.Status (not anything else, e.g . like
> "everything implementing a hypothetical Status interface" which
> would allow for extensibility).
>
> So currently to return a WebDav status code, one must write:
>
> return
> Response.status(ResponseStatus.INSUFFICIENT_STORAGE.getStatusCode())
>
> what is not sice nice, since the "getStatusCode()" method must be
> called to transform the enum into an int.
>
> To solve this, in JAX-RS there is no other solution that to not use
> Response but WebDavResponse -- which has to be implemented exactly
> like Response, what is a lot of double code and work... :-(
>
> So the question is: Is it really annoying that "getStatusCode()"
> must be written or do I worry too much about this inconvenience?
>
> What do you think? Can we live with that, or is a WebDavResponse
> class needed...?
>
> Thanks!
> Markus
>
>