On 03/14/2012 05:19 PM, 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
Ok, thanks,
Marek
>
> 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.
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>