On Mar 29, 2012, at 11:09 AM, Sergey Beryozkin wrote:
> By the way,
> On 28/03/12 22:19, Sergey Beryozkin wrote:
>> Hi Marek
>> On 28/03/12 19:02, Marek Potociar wrote:
>>> Hi Sergey,
>>> What you write makes sense and I see the thought behind your proposal.
>>> If we manage to keep a single Response class for server and client side,
>>> I am ready to support the proposal.
>>>
>>> If we however currently consider having separate ClientResponse on the
>>> client side, I would rather see it as an interface not extending the
>>> core.Response. And as such, I don't like WAE being visible to the
>>> application layer on the client side (since it contains a non-null
>>> Response instance and a getter for it).
>>>
>>> To explain, why I prefer to not extend the Response in the
>>> ClientResponse:
>>>
>>> 1. it does not bring almost any improvements over the current common
>>> response API and keeps most of the issues that need to be resolved
>>> by fine-grained method javadoc-ing.
>>> 2. it does not solve the WAE issue with the contained server-side
>>> Response on the client side - asking users to cast or convert the
>>> WAE response to a ClientResponse is to me very user unfriendly and
>>> looks like a desperate design solution.
>>>
>> Right...
>>>
>>> So right now it seems to me that concrete exceptions for particular
>>> error codes should not be common for client and server. IOW, something
>>> like this:
>>>
>>> ServerErrorException
>>> - WAE
>>> - BadRequestException
>>> - ...
>>> - ClientBadRequestException
>>> - ...
>>>
>>> Alternatively, we can still consider keeping the common Response for
>>> client and server...
>> If it were possible to achieve then it would be good, not sure it would
>> be :-)
>>>
>> IMHO having a number of exception classes able to represent the same
>> error code will be problematic. I can see 3 at least in the example for
>> the status 400 :-).
>>
> That is not a very good argument. I think the better one is that we can have a case where the server application acts as a client, so effectively we can have a single chunk of code where BadRequestException is thrown and ClientBadRequestException is caught, ex:
>
> @Path("/")
> public class RootResource {
>
> @GET
> public Book get(String id) {
> if (!isValidId(id)) {
> throw new BadRequestException();
> } else {
> try {
> return myClient.get(Book.class);
> } catch (ClientBadRequestException ex) {
> throw ServerErrorException();
> }
> }
> }
>
> }
>
> I think it's not cool, not a big problem but is not ideal...
I see. Perhaps it's a matter of personal preference. For instance, I'd much rather see people explicitly doing something about client exceptions thrown as part of a resource method. Either something like the above, or by registering a custom exception mapper that would just rethrow a proper server exception, which would be then mapped in a standard way.
IOW, for me the example above is why i think it's good to distinguish between client and server exceptions.
Marek
> Sergey
>
>> It appears it all revolves around the fact that right now there is an
>> agreement that some of the (new) Response methods do not work well on
>> the server side.
>> Thus one approach is to split it into Client & (server) Response.
>> I wonder what else can we do...
>>
>> Cheers, Sergey
>>
>>> Marek
>>>
>>> On Mar 28, 2012, at 11:59 AM, Sergey Beryozkin wrote:
>>>
>>>> Continuing from the other thread:
>>>>
>>>>
>>>> Note I'm not proposing for WAE to become the root exception type for
>>>> all the exceptions which may originate from processing the HTTP
>>>> request at the JAX-RS level but only for the exceptions identifying
>>>> the server errors.
>>>>
>>>> The client code will be able to:
>>>>
>>>> throw new WebApplicationException(400);
>>>> throw new BadClientRequestException();
>>>>
>>>> I believe the runtime or custom user WebApplicationException mappers
>>>> have to be able to catch BadClientRequestException. In this particular
>>>> case it seems not intuitive to me having the two exception instances
>>>> identifying the same error condition being not related to each other.
>>>>
>>>>
>>>> Now, here is the client code:
>>>>
>>>> String string = request.get(String.class);
>>>>
>>>> We are thinking of introducing 5+ exceptions identifying the server
>>>> errors (or errors reported by the server).
>>>>
>>>> Much depends upon what is decided on the relationship between
>>>> WebApplicationException & exceptions like BadClientRequestException.
>>>>
>>>> I'd prefer them be related so that I can write on the client side:
>>>> try {
>>>> String string = request.get(String.class);
>>>> } catch (NotFoundException ex) {
>>>> // retry with the different address
>>>> } catch (WebApplicationException ex) {
>>>> // catches all the other errors reported by the server, including
>>>> BadClientRequestException
>>>> } catch (ClientException ex) {
>>>> }
>>>>
>>>> The runtime maps the server error codes to individual exceptions such
>>>> as NotFoundException, etc, assuming the matching classes are
>>>> available, otherwise simply wrap it into WebApplicationException()
>>>>
>>>> Does it make sense ?
>>>>
>>>> Sergey
>>>>
>>>> On 27/03/12 17:29, Marek Potociar wrote:
>>>>>
>>>>> On Mar 25, 2012, at 7:07 PM, Sergey Beryozkin wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I'm having one particular concern/question about introducing child
>>>>>> exceptions to do with individual error conditions (400, 404, etc).
>>>>>>
>>>>>> I think that introducing them will require the client runtime to
>>>>>> throw those child exceptions instead of some base exception (such as
>>>>>> WAE), otherwise the client code catching sat NotFoundException won't
>>>>>> be executed if all the client runtime does is throws new
>>>>>> WebApplicationException(404).
>>>>>>
>>>>>> Can we agree it would be the case ?
>>>>>
>>>>> Sounds reasonable to me (for the typed-response retrieval use case).
>>>>>
>>>>>> The other thing that needs to be agreed upon is this: the exceptions
>>>>>> to do with the server errors are only thrown when a typed response
>>>>>> is expected back, example,
>>>>>>
>>>>>> get(Book.class) or similar
>>>>>
>>>>> Yes that's the expectation.
>>>>>
>>>>> Marek
>>>>>
>>>>>> Sergey
>>>>>>
>>>>>> On 14/03/12 16:19, Sergey Beryozkin wrote:
>>>>>>> Hi,
>>>>>>> On 14/03/12 15:53, Marek Potociar wrote:
>>>>>>>> Hi Sergey,
>>>>>>>>
>>>>>>>> just wanted to check if there is any progress with the exception
>>>>>>>> proposal write-up?
>>>>>>>>
>>>>>>>
>>>>>>> I thought we came to the agreement - but I've cloned the repo and
>>>>>>> will
>>>>>>> attach a diff to the JIRA with the proposed code changes - there
>>>>>>> might
>>>>>>> be some delay but I'm on it
>>>>>>>
>>>>>>> thanks, Sergey
>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Marek
>>>>>>>>
>>>>>>>> On 03/05/2012 09:23 PM, Santiago Pericas-Geertsen wrote:
>>>>>>>>> Sergey,
>>>>>>>>>
>>>>>>>>> Still catching up with some e-mails. Do we already have a concrete
>>>>>>>>> proposal for the exact number of client and server exceptions
>>>>>>>>> that we
>>>>>>>>> want to include? If so, please point me to it. Otherwise, we should
>>>>>>>>> put this in writing for the sake of this discussion. Did you
>>>>>>>>> volunteer for that? ;)
>>>>>>>>>
>>>>>>>>> -- Santiago
>>>>>>>>>
>>>>>>>>> On Mar 5, 2012, at 11:06 AM, Sergey Beryozkin wrote:
>>>>>>>>>
>>>>>>>>>> Hi
>>>>>>>>>> On 05/03/12 15:05, Santiago Pericas-Geertsen wrote:
>>>>>>>>>>>
>>>>>>>>>>> On Mar 1, 2012, at 7:41 AM, Sergey Beryozkin wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On 01/03/12 12:11, Sergey Beryozkin wrote:
>>>>>>>>>>>>> by the way, just spotted
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://java.net/projects/jax-rs-spec/sources/git/content/src/jax-rs-api/src/main/java/javax/ws/rs/core/MessageProcessingException.java?rev=62bb71340b7c156684858dac5c9af09aec50430c
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ValidationException is there too - but that is OK -
>>>>>>>>>>>> MessageProcessingException seem problematic though, MBR& MBW are
>>>>>>>>>>>> typed to throw WebApplicationException& InputStream already
>>>>>>>>>>>
>>>>>>>>>>> Could you elaborate as to why you think it's problematic? I see
>>>>>>>>>>> that it doesn't fit in the proposal that you have below, but what
>>>>>>>>>>> if it extended WebApplicationException (client& server)?
>>>>>>>>>>
>>>>>>>>>> Sounds reasonable.
>>>>>>>>>> The question is then, how it will 'co-exist' with other server
>>>>>>>>>> side
>>>>>>>>>> exceptions which are also WebApplicationException children ?
>>>>>>>>>>
>>>>>>>>>> Example, I'm assuming we will have BadClientRequestexception and
>>>>>>>>>> ServerErrorException. The message read failure can be mapped to
>>>>>>>>>> BadClientRequestException and the message write failure can be
>>>>>>>>>> mapped to ServerErrorException. Being also able to catch
>>>>>>>>>> MessageProcessingException won't help the runtime to decide what
>>>>>>>>>> exactly it can be mapped to (400 or 500), so more enhancements
>>>>>>>>>> will
>>>>>>>>>> be needed (MessageReadProcessingException,
>>>>>>>>>> MessageWriteProcessingException ?).
>>>>>>>>>> Additionally, it can happen on the client side on the write...
>>>>>>>>>>
>>>>>>>>>> At th moment it appears that the providers throwing either
>>>>>>>>>> WebApplicationException or IOException is a good way of indicating
>>>>>>>>>> that some kind of message processing exception has occurred
>>>>>>>>>> with the
>>>>>>>>>> cause exceptions also available
>>>>>>>>>>
>>>>>>>>>> Sergey
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -- Santiago
>>>>>>>>>>>
>>>>>>>>>>>>> Should that be gone ? as a summary we seem to have agreed:
>>>>>>>>>>>>>
>>>>>>>>>>>>> - WebApplicationException serves as the base server side
>>>>>>>>>>>>> exception and
>>>>>>>>>>>>> can be used on both ends
>>>>>>>>>>>>> - a limited number of child WebApplicationExceptions is
>>>>>>>>>>>>> introduced
>>>>>>>>>>>>> - InvocationException gets removed
>>>>>>>>>>>>> - ClientInvocation is 'promoted' to represent the base
>>>>>>>>>>>>> client-side
>>>>>>>>>>>>> exception
>>>>>>>>>>>>> - a limited number of child ClientExceptions is introduced
>>>>>>>>>>>>>
>>>>>>>>>>>>> Sergey
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 22/02/12 15:11, Sergey Beryozkin wrote:
>>>>>>>>>>>>>> Sounds like we agree more than we disagree :-)
>>>>>>>>>>>>>> Either way, I support your idea that having the child
>>>>>>>>>>>>>> exceptions
>>>>>>>>>>>>>> can be
>>>>>>>>>>>>>> liked by some/quite a few users,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Cheers, Sergey
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 22/02/12 15:00, Bill Burke wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 2/22/12 9:10 AM, Sergey Beryozkin wrote:
>>>>>>>>>>>>>>>> On 22/02/12 13:41, Bill Burke wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 2/22/12 8:07 AM, Sergey Beryozkin wrote:
>>>>>>>>>>>>>>>>>> Hi Bill
>>>>>>>>>>>>>>>>>> On 22/02/12 12:46, Bill Burke wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 2/21/12 12:06 PM, Sergey Beryozkin wrote:
>>>>>>>>>>>>>>>>>>>> On 21/02/12 10:53, Marek Potociar wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 02/20/2012 03:35 PM, Sergey Beryozkin wrote:
>>>>>>>>>>>>>>>>>>>>>> Here is my proposal.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 1. WebApplicationException serves as the base
>>>>>>>>>>>>>>>>>>>>>> exception
>>>>>>>>>>>>>>>>>>>>>> indicating
>>>>>>>>>>>>>>>>>>>>>> that a problem has occurred at the server side.
>>>>>>>>>>>>>>>>>>>>>> - this exception can be thrown on the server side
>>>>>>>>>>>>>>>>>>>>>> by the
>>>>>>>>>>>>>>>>>>>>>> runtime or
>>>>>>>>>>>>>>>>>>>>>> the application code
>>>>>>>>>>>>>>>>>>>>>> - this exception can be thrown on the client side
>>>>>>>>>>>>>>>>>>>>>> by the
>>>>>>>>>>>>>>>>>>>>>> runtime
>>>>>>>>>>>>>>>>>>>>>> processing the HTTP response containing a status code
>>>>>>>>>>>>>>>>>>>>>>> = 400.
>>>>>>>>>>>>>>>>>>>>>> - this exception class can serve as the base for
>>>>>>>>>>>>>>>>>>>>>> finer-grained
>>>>>>>>>>>>>>>>>>>>>> exceptions, example:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> public class NotFoundException extends
>>>>>>>>>>>>>>>>>>>>>> WebApplicationException {
>>>>>>>>>>>>>>>>>>>>>> public NotFoundException() {
>>>>>>>>>>>>>>>>>>>>>> super(404);
>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> thus making NotFoundException/etc also catchable on
>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>> client
>>>>>>>>>>>>>>>>>>>>>> side
>>>>>>>>>>>>>>>>>>>>>> with the code checking for WebApplicationExceptions...
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 2. Existing InvocationException gets removed
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Sounds good.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> What are the specific exceptions proposed for inclusion
>>>>>>>>>>>>>>>>>>>>> in the
>>>>>>>>>>>>>>>>>>>>> spec?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> No new exceptions are to be *initially* added
>>>>>>>>>>>>>>>>>>>> according to
>>>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>>> specific
>>>>>>>>>>>>>>>>>>>> proposal but it makes it possible to add finer-grained
>>>>>>>>>>>>>>>>>>>> exceptions
>>>>>>>>>>>>>>>>>>>> extending the base ones.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> - WebApplicationException serves as the base for all the
>>>>>>>>>>>>>>>>>>>> problems
>>>>>>>>>>>>>>>>>>>> originated at the server side.
>>>>>>>>>>>>>>>>>>>> - ClientException continues to be the base exception
>>>>>>>>>>>>>>>>>>>> representing
>>>>>>>>>>>>>>>>>>>> some
>>>>>>>>>>>>>>>>>>>> sort of the client-side error but also enhanced at the
>>>>>>>>>>>>>>>>>>>> cost of
>>>>>>>>>>>>>>>>>>>> InvocationException which is to be dropped
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> If we all agree that it makes sense so far then lets
>>>>>>>>>>>>>>>>>>>> review next
>>>>>>>>>>>>>>>>>>>> what
>>>>>>>>>>>>>>>>>>>> additional exceptions such as NotFoundException, etc,
>>>>>>>>>>>>>>>>>>>> representing
>>>>>>>>>>>>>>>>>>>> server-side exceptions, can be added.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Bill proposed few exception classes; IMHO we should
>>>>>>>>>>>>>>>>>>>> limit the
>>>>>>>>>>>>>>>>>>>> number to
>>>>>>>>>>>>>>>>>>>> the ones representing the most common HTTP error code,
>>>>>>>>>>>>>>>>>>>> here is the
>>>>>>>>>>>>>>>>>>>> Bill's list:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> MethodNotAllowedException
>>>>>>>>>>>>>>>>>>>> BadRequestException
>>>>>>>>>>>>>>>>>>>> NotAcceptableException
>>>>>>>>>>>>>>>>>>>> InternalServerErrorException
>>>>>>>>>>>>>>>>>>>> UnauthorizedException
>>>>>>>>>>>>>>>>>>>> UnsupportedMediaTypeException
>>>>>>>>>>>>>>>>>>>> NotFoundException
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I'd drop BadRequestException - this can be anything, and
>>>>>>>>>>>>>>>>>>>> as such
>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> base WebApplicationException can do to deal with it.
>>>>>>>>>>>>>>>>>>>> InternalServerErrorException, UnauthorizedException
>>>>>>>>>>>>>>>>>>>> should
>>>>>>>>>>>>>>>>>>>> probably go
>>>>>>>>>>>>>>>>>>>> too, leaving
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> MethodNotAllowedException
>>>>>>>>>>>>>>>>>>>> NotAcceptableException
>>>>>>>>>>>>>>>>>>>> UnsupportedMediaTypeException
>>>>>>>>>>>>>>>>>>>> NotFoundException
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 3. Existing ClientException gets the getResponse()
>>>>>>>>>>>>>>>>>>>>>> method added.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 4. As far as the client is concerned,
>>>>>>>>>>>>>>>>>>>>>> WebApplicationException and its possible subclasses
>>>>>>>>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>>>>>>>>> indicate
>>>>>>>>>>>>>>>>>>>>>> that the server response is a fault of some sort
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 5. ClientException will *only* indicate that the
>>>>>>>>>>>>>>>>>>>>>> problem
>>>>>>>>>>>>>>>>>>>>>> has
>>>>>>>>>>>>>>>>>>>>>> occurred
>>>>>>>>>>>>>>>>>>>>>> on the client side. As suggested in 3 it will be
>>>>>>>>>>>>>>>>>>>>>> nearly identical to the existing ClientException but
>>>>>>>>>>>>>>>>>>>>>> will have a
>>>>>>>>>>>>>>>>>>>>>> getResponse() added.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Note that its getResponse() method will return 'null'
>>>>>>>>>>>>>>>>>>>>>> for all the
>>>>>>>>>>>>>>>>>>>>>> cases except when the failure was caused by the client
>>>>>>>>>>>>>>>>>>>>>> runtime unable to process the server response (ex, no
>>>>>>>>>>>>>>>>>>>>>> MBR was
>>>>>>>>>>>>>>>>>>>>>> found).
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> You seem to ignore the possibility of client-side
>>>>>>>>>>>>>>>>>>>>> processing
>>>>>>>>>>>>>>>>>>>>> failing
>>>>>>>>>>>>>>>>>>>>> in a request filter/handler chain. Would it make
>>>>>>>>>>>>>>>>>>>>> sense to also add Request to the client exception?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> OK
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> How about approaching this also with a small set of
>>>>>>>>>>>>>>>>>>>>> more
>>>>>>>>>>>>>>>>>>>>> specific
>>>>>>>>>>>>>>>>>>>>> child exceptions?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Do you mean ConnectionFailedException and few others
>>>>>>>>>>>>>>>>>>>> ? I'd
>>>>>>>>>>>>>>>>>>>> probably
>>>>>>>>>>>>>>>>>>>> add
>>>>>>>>>>>>>>>>>>>> ConnectionFailedException for a start...
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I agree with adding COnnectionFailedException, I don't
>>>>>>>>>>>>>>>>>>> agree with
>>>>>>>>>>>>>>>>>>> removing the excerptions you suggested.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> It's really to do with coming up with some very minimal
>>>>>>>>>>>>>>>>>> set, as
>>>>>>>>>>>>>>>>>> opposed
>>>>>>>>>>>>>>>>>> to saying that no, BadRequestException, can not occur
>>>>>>>>>>>>>>>>>> often
>>>>>>>>>>>>>>>>>> enough.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> For ex, BadRequestException, can be thrown in a number of
>>>>>>>>>>>>>>>>>> cases, and
>>>>>>>>>>>>>>>>>> thus it's no more useful on the client side than the base
>>>>>>>>>>>>>>>>>> WebApplicationException...Same for
>>>>>>>>>>>>>>>>>> InternalServerErrorException.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> UnauthorizedException - may be should stay, though the
>>>>>>>>>>>>>>>>>> jaxrs
>>>>>>>>>>>>>>>>>> runtime
>>>>>>>>>>>>>>>>>> itself won't throw it...
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> It's not a big deal, if we were indeed to go for adding
>>>>>>>>>>>>>>>>>> few
>>>>>>>>>>>>>>>>>> child
>>>>>>>>>>>>>>>>>> exceptions, if we had 5 or 8 added, the question is how
>>>>>>>>>>>>>>>>>> far
>>>>>>>>>>>>>>>>>> should we
>>>>>>>>>>>>>>>>>> really go... I guess I'm still worried about the class
>>>>>>>>>>>>>>>>>> explosion more
>>>>>>>>>>>>>>>>>> than anything else :-)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Well, the JAX-RS 2.0 spec is inconsistent on this sort of
>>>>>>>>>>>>>>>>> thing. We
>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>> methods in request/responsebuilder for http headers that
>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>> rarely
>>>>>>>>>>>>>>>>> used
>>>>>>>>>>>>>>>>> (allow for example) and don't have ones for things that are
>>>>>>>>>>>>>>>>> often used
>>>>>>>>>>>>>>>>> (accept).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> We should do one or the other across the board. IMO, I
>>>>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>>>> see the
>>>>>>>>>>>>>>>>> problem with an explosion of methods/classes that cover
>>>>>>>>>>>>>>>>> hte HTTP
>>>>>>>>>>>>>>>>> specification. While Sergey may find BadRequestException
>>>>>>>>>>>>>>>>> unuseful,
>>>>>>>>>>>>>>>>> somebody else might.
>>>>>>>>>>>>>>>> I think you've misinterpreted me. I was talking about the
>>>>>>>>>>>>>>>> utility of
>>>>>>>>>>>>>>>> BadRequestException while trying to justify the conservative
>>>>>>>>>>>>>>>> approach
>>>>>>>>>>>>>>>> which I believe the spec should take with regard to
>>>>>>>>>>>>>>>> introducing new
>>>>>>>>>>>>>>>> classes which to be honest do not add anything new, example,
>>>>>>>>>>>>>>>> that is
>>>>>>>>>>>>>>>> all
>>>>>>>>>>>>>>>> is already covered by the spec/api. That said, I'm not going
>>>>>>>>>>>>>>>> to spend
>>>>>>>>>>>>>>>> much time on arguing against extra 3 or whatever classes
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I think you misunderstood me :) If you look at
>>>>>>>>>>>>>>> RequestHeader or
>>>>>>>>>>>>>>> RequestBuilder, for example, there's methods there that would
>>>>>>>>>>>>>>> rarely be
>>>>>>>>>>>>>>> used (i.e. allow). I'm saying either we cover everything or
>>>>>>>>>>>>>>> we be
>>>>>>>>>>>>>>> consistent throughout the spec and remove classes/methods
>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>> rarely (if ever) be used.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>
>>>>
>>>>
>>>
>
>
> --
> Sergey Beryozkin
>
> Talend Community Coders
> http://coders.talend.com/
>
> Blog: http://sberyozkin.blogspot.com