> I don't understand why WorkflowException should be mapped to > INTERNAL_SERVER_ERROR: you get workflow exceptions when something is > not allowed within the current workflow instance, for example. There is no > error on the server, the error is on the client asking for a workflow action > not > available for various reasons.
As far as I see, WorkflowException also wraps ActivitiException thrown by runtimeService, that can indicate problems with Activiti engine. Anyway I do not have strong opinion regarding WorkflowException, if you think it is mostly causes by wrong client argument, let set it back to BAD_REQUEST. > Similarly for PersistenceException - thrown for example when a duplicate key > is found: this is not happening (under normal conditions) for a server fault > but for a client's. Normally, in case of duplicate keys DataIntegrityViolationException is thrown (mapped to HTTP.CONFLICT). org.apache.ibatis.exceptions.PersistenceException can indicate following: - error building SqlSession; - error parsing SQL Mapper Configuration; - cache problem; - session problem; - transaction exception IMO it mostly caused by server errors as by wrong client request - not absolutely sure. Regards, Andrei. > -----Original Message----- > From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] > Sent: Freitag, 18. Januar 2013 15:20 > To: dev@syncope.apache.org > Subject: Re: Exception propagation in Rest interface: HTTP header vs body > for details > > On 18/01/2013 15:04, Andrei Shakirin wrote: > > Hi, > > > > From proposals regarding remote exceptions in [1], I am going to do the > following during CXF migration: > > 1) Update HTTP mapping codes (see "Mapping exceptions to HTTP codes") > > I don't understand why WorkflowException should be mapped to > INTERNAL_SERVER_ERROR: you get workflow exceptions when something is > not allowed within the current workflow instance, for example. There is no > error on the server, the error is on the client asking for a workflow action > not > available for various reasons. > > > Similarly for PersistenceException - thrown for example when a duplicate key > is found: this is not happening (under normal conditions) for a server fault > but for a client's. > > > 2) Update some checked exceptions to runtime ones (see "Checked vs > > Runtime exceptions") > > Sounds reasonable. > > Regards. > > >> -----Original Message----- > >> From: Andrei Shakirin [mailto:ashaki...@talend.com] > >> Sent: Montag, 7. Januar 2013 10:01 > >> To: dev@syncope.apache.org > >> Subject: RE: Exception propagation in Rest interface: HTTP header vs > >> body for details > >> > >> I have tried to summarize remote exceptions mapping as well as some > >> improvement ideas in [1]. > >> [1] is also linked from [2]. > >> Review, remarks, discussions are welcome. > >> > >> Cheers, > >> Andrei. > >> > >> [1] > >> > https://cwiki.apache.org/confluence/display/SYNCOPE/Remote+Exceptions > >> [2] > >> > https://cwiki.apache.org/confluence/display/SYNCOPE/REST+API+upgrade > >> > >> > >>> -----Original Message----- > >>> From: Andrei Shakirin [mailto:ashaki...@talend.com] > >>> Sent: Freitag, 14. Dezember 2012 09:37 > >>> To: dev@syncope.apache.org > >>> Subject: RE: Exception propagation in Rest interface: HTTP header vs > >>> body for details > >>> > >>> Yep, will go this way: keep current propagation one to one plus more > >>> verbose exception in HTTP body (perhaps on the second step). > >>> Thanks for participating in discussion. > >>> > >>> Cheers, > >>> Andrei. > >>> > >>>> -----Original Message----- > >>>> From: Sergey Beryozkin [mailto:sberyoz...@gmail.com] > >>>> Sent: Donnerstag, 13. Dezember 2012 18:34 > >>>> To: dev@syncope.apache.org > >>>> Subject: Re: Exception propagation in Rest interface: HTTP header > >>>> vs body for details > >>>> > >>>> On 13/12/12 16:45, Francesco Chicchiriccò wrote: > >>>>> On 13/12/2012 14:27, Sergey Beryozkin wrote: > >>>>>> Hi > >>>>>> On 13/12/12 12:42, Andrei Shakirin wrote: > >>>>>>> Hi, > >>>>>>> > >>>>>>> I am working on Rest interface migration (to Apache CXF) and > >>>>>>> analysing exception propagation from service to client. > >>>>>>> Actually SyncopeClientCompositeErrorException is sent using: > >>>>>>> > >>>>>>> a) ExceptionType HTTP header containing exception type > >>>>>>> (enumeration > >>>>>>> SyncopeClientExceptionType) > >>>>>>> > >>>>>>> b)<ExceptionType>.element HTTP header as list of strings for > >>>>>>> error details (that are used to fill > >>>>>>> SyncopeClientException.elements) > >>>>>>> > >>>>>>> I find that fine at the moment, as far as details information is > >>>>>>> only simple and short list of strings. Potentially it is > >>>>>>> possible to have more complex and long structures in exception > >> details. > >>>>>>> Therefore the question is does it make sense to use HTTP header > >>>>>>> only for ExceptionType and send details in HTTP body? > >>>>>>> It means that we will change network protocol between client and > >>>>>>> service, not sure how critical it is for existing Syncope users. > >>>>>>> > >>>>>>> There are 2 alternatives: > >>>>>>> > >>>>>>> a) leave the propagation as it is: send type and details in HTTP > >>>>>>> headers. In the future additional information exceptional still > >>>>>>> can be sent with HTTP body. > >>>>>>> > >>>>>>> b) send only ExceptionType in HTTP header and details element in > >>>>>>> HTTP body. > >>>>>>> > >>>>>>> Do you have any preferences for (a) and (b) or there are other > >>>>>>> alternatives? > >>>>>> Perhaps it might make sense to keep a simple HTTP header anyway, > >>>>>> for the receivers to be optionally able to quickly check the > >>>>>> exception type without having to read the response, and also > >>>>>> return the body with all the details, including the actual > >>>>>> exception type, so that the whole info can then be analyzed on > >>>>>> the client side after the request has been completed, so one more > >>>>>> possible option > >>>>>> :-) > >>>>> Hi, > >>>>> I like this (c) option as well: > >>>>> 1. ExceptionType + elements in the HTTP header (like as now) 2. > >>>>> HTML > >>>>> (short) body with more verbose description, possibly localized > >>>>> > >>>>> (1) could be used by 3rd party REST clients while (2) could be > >>>>> used to provide better error message for admin console. > >>>>> > >>>> Hi, I'm rereading and I guess I may've repeated what Andrei already > >>>> suggested with his option a) :-) > >>>> > >>>> Either way, looks like we all in agreement > >>>> > >>>> Cheers, Sergey > >>>> > >>>>> Regards. > >>>>> > > > -- > Dott. Francesco Chicchiriccò > Tel +393290573276 > > Amministratore unico @ Tirasa S.r.l. > Viale D'Annunzio 267 - 65127 Pescara > Tel +39 0859116307 / FAX +39 0859111173 > http://www.tirasa.net > > ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member > http://people.apache.org/~ilgrosso/ > > "To Iterate is Human, to Recurse, Divine" > (James O. Coplien, Bell Labs) > > > -- > Francesco Chicchiriccò > > ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member > http://people.apache.org/~ilgrosso/
