dev@jsr311.java.net

Re: JSR311: ResponseBuilder

From: Marc Hadley <Marc.Hadley_at_Sun.COM>
Date: Tue, 02 Sep 2008 08:27:11 -0400

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?
>
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.

>> 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. BTW, what's the use case for throwing a subclass ?

>> 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 ?

Marc.

---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.