So, how would I go about adding this new EIP pattern for handling exceptions? Anybody have any suggestions on what and how it gets configured and how it actually catches the exceptions? I'm guessing it has to be some sort of endpoint that allows you to specify the type of exception to catch and where to route the exception where it is caught, but I'm not sure how this will actually work on the code level.
-Jeff jpuro wrote: > > 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#a6082345 Sent from the ServiceMix - Dev forum at Nabble.com.
