FWIW, here are some of the thoughts about Response vs. ClientResponse based on my experiments with updating the filtering API:
One way to resolve the issues of the common type is to completely decouple the Response and ClientResponse. This would bring the benefits of a dedicated API for each side. However, it also brings a question where we should stop the split. Should we also introduce a separate Status and StatusType for the client side? Or should we reuse the ones defined in Response? Would reuse confuse users? Would introduction of the new client-side response status types confuse users more? OR should we just stick to the ints and not introduce any type for the client-side status codes? Also, with this solution reusing WAE as a common super-type of all exceptions representing server-side errors is not possible IMO.
Another option is to extend the ClientResponse from the Response. This makes the Response.Status/StatusType reuse more natural, but client side suffers from the "weird method" issues that we identified in the common Request/Response model. IOW, one of the main issues why we started this exercise has not gone away... Also, reusing WAE as a common exception super-type is problematic due to the need to downcast the Response in the WAE on the client side or do some other similar tricks.
The last option is to keep the common Response mostly as is and rollback only the changes in the Request. The advantage is that reuse of the member types is natural on both, client and server. The disadvantage is that the "weird method" syndrome is visible again on both, client and server. The good thing would be that with new filtering infrastructure not based on the Request/Response types, the problem would mainly be visible in some client scenarios. Also reusing WAE as the common super-type becomes more possible s well as ResponseBuilder.
I wish Status & StatusType were not defined inside the core.Response. Things would have been much more simpler. All in all, seems to me we should either do a complete radical cut between the client and the server or keep the common Response. To me the middle option is just not appealing enough. It looks more like a collection of the problems from both worlds rather than a good solution.
Thoughts?
Marek
On Mar 29, 2012, at 5:26 PM, Bill Burke wrote:
> You could punt on server-side exceptions and just have a client hierarchy. (If we went the ClientResponse route).
>
> On 3/29/12 10:26 AM, Santiago Pericas-Geertsen wrote:
>> Marek, Sergey,
>>
>> Generally speaking, I like the idea of sharing and having fewer classes. However, when you look at the details (like WAE) the server-centric style of JAX-RS 1.X keeps popping up :( We sort of concluded the same for Request, Response, filters, etc.
>>
>> It seems almost inevitable that we'll end up arriving at the same conclusion for exceptions. If that's the case, I think we should only define new exceptions for the most common error conditions (should only be a few) and leave the general case to WAE (and its client counterpart).
>>
>> -- Santiago
>>
>> On Mar 29, 2012, at 8:13 AM, Marek Potociar wrote:
>>
>>>
>>> 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
>>>
>>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com