> -----Ursprüngliche Nachricht-----
> Von: "Marc Hadley" <Marc.Hadley_at_Sun.COM>
> Gesendet: 02.09.08 14:27:29
> An: dev_at_jsr311.dev.java.net
> Betreff: Re: JSR311: ResponseBuilder
>
> On Sep 2, 2008, at 6:57 AM, Paul Sandoz wrote:
>
> > Stephan Koops wrote:
> >> Hi,
> >> Request.evaluatePreconditions(..) returns a ResponseBuilder, which
> >> contains the status 413 (Precondition failed), if the Preconditons
> >> doesn't match. If the request is is GET (or HEAD) it could also be
> >> 304 (Not modified). Than the server MUST (says HTTP) contains also
> >> e.g. expires, Cache-Control and others (see http://tools.ietf.org/html/rfc2616#section-10.3.5)
> >> .
> >>
> >
> > Does it really matter if such headers are added to 412 responses?
Cache-Control etc. headers are not really useful in error messages
> Also note the ResponseBuilder.clone method so a user can build() a
> clone to determine the return type and then add any additional headers
> to the original if required.
>
> Given there are workarounds I think its too late to consider this
> change now.
Ok, if it is too late, than it is too late.
> >> And a small other point: We discussed about the question, if a
> >> RuntimeEnvironment is allowed to throw a subclass of
> >> WebApplicationException where the spec defines a WebApplicationExc.
> >> The answer to this question was "yes, why not?", but it is not
> >> defined in the spec now.
>
> Its not disallowed.
The spec says, that it throws a WebApplicationException. You could interpret this, that you must exactly throw this class and no subclass of it.
> BTW, what's the use case for throwing a subclass ?
I want to bring additional metadata as attribute into the Exception, e.g. allowed media types for a status 406 or 415. Than the default exception mapper for the WebApplicationException catches it and could give details, e.g. the allowed mediatype. For this I need this data in the WebApplicationException.
> >> We should also define, that a runtime environment MUST NOT use
> >> exception mapper for this sub classes, but only for WebAppExc. This
> >> is needed, because an app developer could give his own exception
> >> mapper for WebAppExc, which should handle the requests thrown by
> >> the runtime environment.
>
> I don't really understand the concern. If an impl throws a custom
> subclass and an application has an exception mapper for it then the
> result is non-portable (obviously) but I don't see any other issue ?
The idea for this results in my explanation before in this email. If I catch the runtime environment WebAppExc subclass for e.g 406 or 415, than the application provided exception mapper for the WebAppExc will not get this subclass exception, but the sense, that this exception must be handled as described in section 3.3.4 is, that this is possible.
best regards
Stephan
________________________________________________________________________
Schon gehört? Bei WEB.DE gibt' s viele kostenlose Spiele:
http://games.entertainment.web.de/de/entertainment/games/free/index.html