I hear these arguments. My use case may not have been the best example, but I have run into many other situations where the business requires that we handle runtime exceptions more gracefully and allow for smarter routing. Perhaps just adding a new EIP pattern that specifically can handle exceptions would do the trick.
-Jeff Philip Dodds-2 wrote: > > I Agree that I'm not sure you should build in exception routing when it is > better placed as another component that handles the Call and return of an > exception. It would seem that when building up services you should be > handling exceptions and returning faults/exceptions in a clean fashion and > that the routing of exceptions is better placed since I can see there > becoming increasing details rquired for the routing. Just thinking of a > SQLException and then needing the sqlCode in order to determine the > "meaning" of the exception before routing. > > Philip > > On 8/25/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote: >> >> I guess that if you want to handle exceptions in a JBI compliant way, >> you should put in the flow some specific components to do that. >> >> First, we need to make a distinction between faults and errors. >> Imho, faults are unrecoverable problems, due to the message itself. >> Errors are runtime problems, which may be able to be solved at >> a later time. >> >> In your example, depending on the reason why the data could not be >> stored in the database, the component should return a fault >> (if the data is corrupted) or an error (the database is down). >> >> In your use case, the error should be catched by a simple component >> (an EIP pattern) between the http component and the business >> component which would act as a normal proxy when no errors are >> reported, and redirect the flow elsewhere when an error occurs. >> >> Also, I don't really understand the "friendly error" concept ;) >> The http component is not designed to be a jsp server, so you >> won't have any nice interface there. The output should be an xml. >> If you want a nice interface, you should deploy a web app which >> would call the jbi bus and return a nice html page when an error >> occurs. >> >> Last, while I think declarative transactions may be really useful >> for POJO based components (servicemix-jsr181, or the yet to be >> defined new component, see other threads on the list), >> it would be difficult to apply it in a real JBI world. >> >> Let's discuss it, it' s just my thoughts. >> >> On 8/25/06, jpuro <[EMAIL PROTECTED]> wrote: >> > >> > >> > I think it would be useful to add declarative exception handling to >> > ServiceMix. The usefullness of such a feature can be seen from the >> > following simple use case involving a client submitting an order to a >> > fulfillment company: >> > >> > 1) The use case starts when the client sends an order to an HTTP >> endpoint >> > exposed in ServiceMix. The message representing the order is routed to >> a >> > business service component. >> > >> > 2) The business service component attempts to process the Order and >> save >> > it >> > to a database. However, an exception occurs during this process and >> gets >> > bubbled up. The fulfillment company would like to be notified via >> email >> > when an order fails to be processed. Since we have configured the >> > business >> > service component to pass all exceptions to an email component, the >> flow >> > moves to step 3. >> > >> > 3) The email component sends out an email notification to the >> fulfillment >> > company indicating that an error occurred while processing the order. >> > >> > 4) After the email has been sent out, the flow moves to another >> component >> > that returns a more user friendly error message to the original HTTP >> > endpoint. This way we do not send back a hard to read error message to >> > the >> > client. >> > >> > The purpose of such a flow is that we handle exceptions more gracefully >> > than >> > currently is supported by ServiceMix. Instead of bubbling up >> exceptions >> > to >> > the calling component, we should allow components to change the flow of >> a >> > message when an exception occurs. >> > >> > The configuration could look something like the following: >> > >> > <activationSpec componentName="businessServiceComponent" >> > service="example:businessService" >> > >> > >> exceptionDestionationService="example:emailService"> >> > <sm:component> >> > <bean class=" >> com.mycompany.MyClass >> > "/> >> > </sm:component> >> > </activationSpec> >> > >> > Alternatively, perhaps we can just use AOP to catch exceptions that >> occur >> > within a component: >> > >> > <sm:exceptionHandler >> > exceptionType="javax.jbi.messaging.MessagingException" >> > destinationService="example:emailService"> >> > >> > <activationSpec >> componentName="businessServiceComponent" >> > >> service="example:businessService"> >> > <sm:component> >> > <bean class=" >> > com.mycompany.MyClass"/> >> > </sm:component> >> > </activationSpec> >> > >> > </sm:exceptionHandler> >> > >> > >> > Here are a few concerns of mine: >> > >> > 1) The problem with the first example configuration is that it doesn't >> > allow you to get creative with how certain types of exceptions are >> > handled, >> > it just acts like a catch all. We may need to create a more flexible >> way >> > of >> > configuring exception handling. >> > >> > 2) Because of the way JBI service units/assemblies are packaged and >> > deployed, would this work? Is there any discussion on declaratively >> > handling exceptions in the JBI spec? >> > >> > Regards, >> > >> > Jeff >> > -- >> > View this message in context: >> > >> http://www.nabble.com/Declarative-Exception-Handling-in-ServiceMix-tf2161788.html#a5974450 >> > Sent from the ServiceMix - Dev forum at Nabble.com. >> > >> > >> >> >> -- >> Cheers, >> Guillaume Nodet >> >> > > -- View this message in context: http://www.nabble.com/Declarative-Exception-Handling-in-ServiceMix-tf2161788.html#a5986153 Sent from the ServiceMix - Dev forum at Nabble.com.
