Hi Sergei, > I agree to some extent but more regarding throwing the exceptions - note > Response is meant to represent HTTP response as is but not only 'good' > Response, so if it is in the signature then the client is kind of expected to > handle it.
Agree. >From other side my argumentation is following: as far as user registers >exception mapper on client side (it is not mandatory), why not handle all >errors in consistent way via exception mapper? In some special cases, when >user would like to process "bad" HTTP Response in the business method, he can >return null instead exception in exception mapper . > We can get the proxy client side to check the the mappers even if Response > is returned, but only if status is >= 300. So if status is 200 then you'd > still get > no exception if it is not 201 or no Location header is available. Yep, it should be OK. If you have no objections, I will try to do this optimization myself as first exercise in CXF-JAXRS ;) > Perhaps it is simpler to simply register a client side JAX-RS 2.0 > ClientResponseInterceptor and throw if it is not 201 ? I also consider it as quick solution for Syncope. Regards, Andrei. > -----Original Message----- > From: Sergey Beryozkin [mailto:[email protected]] > Sent: Mittwoch, 30. Januar 2013 23:46 > To: Andrei Shakirin > Cc: [email protected] > Subject: Re: [CXF.REST] Exception mapper on the client in case of Response > retun value > > Hi Andrei > > On 30/01/13 12:58, Andrei Shakirin wrote: > > Hi Sergei, > > > >> ExceptionMapper is only used on the server side, on the client side > >> there's no concept of mapping error responses to custom exceptions > >> when fluent API is used (standard 2.0, CXF WebClient), so in CXF it > >> is custom ResponseExceptionMapper provider which can be used by the > >> proxy client runtime to map an error status code to one of declared > >> exception classes, for example > >> > >> Book getBook() throws BookNotFoundException; > >> > >> CXF client can register ResponseExceptionMapper and convert say 404 > >> to BookNotFoundException; > > > > I have discovered a little bit different behaviour in CXF 2.7.0: > > if service interface method returns object - client exception mapper is > invoked, independent if exceptions are declared or not. > > Yes - there was a request to support RuntimeException mappers even > without the declared exceptions > > > If service interface method returns Response, client exception mapper isn't > invoked. > > > >>> Response response = connectorService.create(connectorTO); > >>> if (response.getStatus() != > org.apache.http.HttpStatus.SC_CREATED) { > >>> throw (RuntimeException) > >> clientExceptionMapper.fromResponse(response); > >>> } > >> Where is this code coming from ? > > > > It is our code from Syncope project. Currently we should manually call > exception mapper on client side for all methods returning Response. > > > >> The expectation (consistent with 2.0 client API) is that if Response > >> is returned then the client needs to handle it itself, including > >> checking the headers and the status. > > > > Sure, client can do it (see code above), but need additional code for > methods returning Response - looks a little bit ugly for me. > > > I agree to some extent but more regarding throwing the exceptions - note > Response is meant to represent HTTP response as is but not only 'good' > Response, so if it is in the signature then the client is kind of expected to > handle it. > > >> > >> Do you need checking a client side mapper even for Response for > >> consistency purposes, example, the application code is expected to > >> have catch statements whether it is Response or MyCustomType which is > >> returned from a method ? > > > > Yep, it is the case. Client code expects exceptions, they are coming > automatically from mapper for all methods except returning Response ones > (here we need extra code). > > > We can get the proxy client side to check the the mappers even if Response > is returned, but only if status is >= 300. So if status is 200 then you'd > still get > no exception if it is not 201 or no Location header is available. > > Perhaps it is simpler to simply register a client side JAX-RS 2.0 > ClientResponseInterceptor and throw if it is not 201 ? > > What do you think ? > > Cheers, Sergey > > > Regards, > > Andrei. > > > >> -----Original Message----- > >> From: Sergey Beryozkin [mailto:[email protected]] > >> Sent: Mittwoch, 30. Januar 2013 12:33 > >> To: [email protected] > >> Subject: Re: [CXF.REST] Exception mapper on the client in case of > >> Response retun value > >> > >> Hi Andrei > >> On 30/01/13 10:21, Andrei Shakirin wrote: > >>> Hi, > >>> > >>> I see that registered ExceptionMapper is not invoked on the client > >>> side, if > >> service interface returns Response. > >>> Not sure is it JAX-RS specified or desired behaviour. > >>> > >> ExceptionMapper is only used on the server side, on the client side > >> there's no concept of mapping error responses to custom exceptions > >> when fluent API is used (standard 2.0, CXF WebClient), so in CXF it > >> is custom ResponseExceptionMapper provider which can be used by the > >> proxy client runtime to map an error status code to one of declared > >> exception classes, for example > >> > >> Book getBook() throws BookNotFoundException; > >> > >> CXF client can register ResponseExceptionMapper and convert say 404 > >> to BookNotFoundException; > >> > >>> From one side client has enough information in Response to deal > >>> with > >> errors. > >>> From other side, if service interface has mix of methods > >>> returning > >> Response and normal objects, it causes code like this for all "Response" > >> methods: > >>> Response response = connectorService.create(connectorTO); > >>> if (response.getStatus() != > org.apache.http.HttpStatus.SC_CREATED) { > >>> throw (RuntimeException) > >> clientExceptionMapper.fromResponse(response); > >>> } > >> Where is this code coming from ? > >> > >> > >>> > >>> I can imagine that even for methods returning Response, client > >>> exception > >> mapper is invoked for error response codes. > >>> WDYT? > >> > >> The expectation (consistent with 2.0 client API) is that if Response > >> is returned then the client needs to handle it itself, including > >> checking the headers and the status. > >> > >> Do you need checking a client side mapper even for Response for > >> consistency purposes, example, the application code is expected to > >> have catch statements whether it is Response or MyCustomType which is > >> returned from a method ? > >> > >> Cheers, Sergey > >> > >>> > >>> Regards, > >>> Andrei. > >>> > >
