Re: Declarative Exception Handling in ServiceMix
Where are you on this component? Do you plan on donating the code to the ServiceMix project? I also have a use for such a component, but haven't developed one yet. Regards, Jeff Ralf Wunsch wrote: gnodet wrote: A few questions: * How are the errorHandler and errorHandlerConfig related ? * If I want to handle a given exception specifically, i guess I need to implement a custom errorHandler, right ? * how does the errorHandler plug into the jbi container ? * If i have more than one ErrorHandlerComponent in the flow it should be possible to use one ErrorHandler with different configurations for each ErrorHandlerComponent (e.g. to specify different targets for different types of failed messages). To provide this the configuration for the ErrorHandler has been extracted and assembled in the ErrorHandlerConfig XBean. * In my opinion the error handler hook and the handlers strategy should be separated. I am involved in a migration project (from a commercial EAI solution to open source). In the current EAI system an error handler is always implemented. We want to migrate this solution that is based on a set of database stored rules. I think there can be a lot of error handler strategy implementations. One default handler can be an implementation as discussed before. * At this time i am using my own extension of the JBIContainer. This extension registeres an ErrorEventListener as EventListener by default. I have not found a way to configure event listeners in the deployment descriptor. The ErrorHandler is a attribute of the extended container (the getter/setter methods are using the ErrorEventListerners 'errorHandler' attribute). Best regards, Ralf Wunsch -- View this message in context: http://www.nabble.com/Declarative-Exception-Handling-in-ServiceMix-tf2161788.html#a7019056 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Declarative Exception Handling in ServiceMix
Ralf Wunsch wrote: We are starting a new EAI project. At this time ServiceMix is our choice for the implementation plattform. We have strong requirements for monitoring and control issues. At this one aspect is the handling of unexpected errors. For this reason i have implemented the following error handler solution. The error handling solution delegates errors or faults detected in analysis of the MessageExchange objects to an ErrorHandler implemented as XBean. This bean is used by an ErrorHandlerComponent (a JBI component embedded in the flow) or by the JBIContainer (the centralized way) or both. http://www.nabble.com/file/290/error-handler-embedding.png The ErrorHandler can cancel transactions and stop the container or the source component (all cofigurable). Furthermore it's possible to route the error or fault messages and the actuating message to a configurable target. In this case ist possible to embed one or more ErrorHandlerComponents into the flow. http://www.nabble.com/file/291/error-handler-flow.png Such an ambedded ErrorHandlerComponent borrowed by the EIP WireTap ensures that the rerouted message from the source will be in a well know format (the centralised approach can't accomplish this). The embedded and the centralized approach can be used in combination. For synchronization the ErrorHandlerComponent sets a Property on the outgoing MessageExchange and the ErrorEventListener does nothing as long as this property can be found in the MessageEchange which signals a fault or an error. A sample configuration... lt;bean id=errorHandler class=de.eval.eai.error.DefaultErrorHandlergt; lt;/beangt; ... lt;bean id=errorHandlerConfig class=de.eval.eai.error.ErrorHandlerConfiggt; lt;property name=shutdownOnFault value=true /gt; lt;property name=rollbackOnFault value=false /gt; lt;/beangt; ... lt;test:container id=jbi useMBeanServer=true createMBeanServer=false dumpStats=true statsInterval=10 errorHandler=#errorHandler errorHandlerConfig=#errorHandlerConfiggt; ... lt;sm:activationSpecsgt; ... lt;sm:activationSpec componentName=errorHandlergt; lt;sm:componentgt; lt;eai:componentgt; lt;eai:endpointsgt; lt;eai:errorHandler service=errorHandler endpoint=endpointgt; lt;eai:targetgt; lt;eai:exchange-target service=transformer /gt; lt;/eai:targetgt; lt;eai:disqualifyTargetgt; lt;eai:exchange-target service=failedQueue /gt; lt;/eai:disqualifyTargetgt; lt;eai:errorTargetgt; lt;eai:exchange-target service=errorQueue /gt; lt;/eai:errorTargetgt; lt;eai:faultTargetgt; lt;eai:exchange-target service=faultQueue /gt; lt;/eai:faultTargetgt; lt;property name=shutdownOnFault value=true /gt; lt;property name=rollbackOnFault value=false /gt; lt;/eai:errorHandlergt; lt;/eai:endpointsgt; lt;/eai:componentgt; lt;/sm:componentgt; lt;/sm:activationSpecgt; ... Two questions: Ist this a accurate ServieMix way (in accordance with the ideas of ServiceMix)? Is it on behalf of the project or the communitiy to reuse this solution? Thanks, Ralf Wunsch -- View this message in context: http://www.nabble.com/Declarative-Exception-Handling-in-ServiceMix-tf2161788.html#a6658179 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: Declarative Exception Handling in ServiceMix
Sounds good. Nice work ! A few questions: * How are the errorHandler and errorHandlerConfig related ? * If I want to handle a given exception specifically, i guess I need to implement a custom errorHandler, right ? * how does the errorHandler plug into the jbi container ? If you want to donate this code, feel free to raise a JIRA issue and attach the code. I think it would be a nice addition. On 10/5/06, Ralf Wunsch [EMAIL PROTECTED] wrote: Ralf Wunsch wrote: We are starting a new EAI project. At this time ServiceMix is our choice for the implementation plattform. We have strong requirements for monitoring and control issues. At this one aspect is the handling of unexpected errors. For this reason i have implemented the following error handler solution. The error handling solution delegates errors or faults detected in analysis of the MessageExchange objects to an ErrorHandler implemented as XBean. This bean is used by an ErrorHandlerComponent (a JBI component embedded in the flow) or by the JBIContainer (the centralized way) or both. http://www.nabble.com/file/290/error-handler-embedding.png The ErrorHandler can cancel transactions and stop the container or the source component (all cofigurable). Furthermore it's possible to route the error or fault messages and the actuating message to a configurable target. In this case ist possible to embed one or more ErrorHandlerComponents into the flow. http://www.nabble.com/file/291/error-handler-flow.png Such an ambedded ErrorHandlerComponent borrowed by the EIP WireTap ensures that the rerouted message from the source will be in a well know format (the centralised approach can't accomplish this). The embedded and the centralized approach can be used in combination. For synchronization the ErrorHandlerComponent sets a Property on the outgoing MessageExchange and the ErrorEventListener does nothing as long as this property can be found in the MessageEchange which signals a fault or an error. A sample configuration... lt;bean id=errorHandler class=de.eval.eai.error.DefaultErrorHandlergt; lt;/beangt; ... lt;bean id=errorHandlerConfig class=de.eval.eai.error.ErrorHandlerConfiggt; lt;property name=shutdownOnFault value=true /gt; lt;property name=rollbackOnFault value=false /gt; lt;/beangt; ... lt;test:container id=jbi useMBeanServer=true createMBeanServer=false dumpStats=true statsInterval=10 errorHandler=#errorHandler errorHandlerConfig=#errorHandlerConfiggt; ... lt;sm:activationSpecsgt; ... lt;sm:activationSpec componentName=errorHandlergt; lt;sm:componentgt; lt;eai:componentgt; lt;eai:endpointsgt; lt;eai:errorHandler service=errorHandler endpoint=endpointgt; lt;eai:targetgt; lt;eai:exchange-target service=transformer /gt; lt;/eai:targetgt; lt;eai:disqualifyTargetgt; lt;eai:exchange-target service=failedQueue /gt; lt;/eai:disqualifyTargetgt; lt;eai:errorTargetgt; lt;eai:exchange-target service=errorQueue /gt; lt;/eai:errorTargetgt; lt;eai:faultTargetgt; lt;eai:exchange-target service=faultQueue /gt; lt;/eai:faultTargetgt; lt;property name=shutdownOnFault value=true /gt; lt;property name=rollbackOnFault value=false /gt; lt;/eai:errorHandlergt; lt;/eai:endpointsgt; lt;/eai:componentgt; lt;/sm:componentgt; lt;/sm:activationSpecgt; ... Two questions: Ist this a accurate ServieMix way (in accordance with the ideas of ServiceMix)? Is it on behalf of the project or the communitiy to reuse this solution? Thanks, Ralf Wunsch -- View this message in context: http://www.nabble.com/Declarative-Exception-Handling-in-ServiceMix-tf2161788.html#a6658179 Sent from the ServiceMix - Dev mailing list archive at Nabble.com. -- Cheers, Guillaume Nodet
Re: Declarative Exception Handling in ServiceMix
On 10/5/06, Ralf Wunsch [EMAIL PROTECTED] wrote: gnodet wrote: A few questions: * How are the errorHandler and errorHandlerConfig related ? * If I want to handle a given exception specifically, i guess I need to implement a custom errorHandler, right ? * how does the errorHandler plug into the jbi container ? * If i have more than one ErrorHandlerComponent in the flow it should be possible to use one ErrorHandler with different configurations for each ErrorHandlerComponent (e.g. to specify different targets for different types of failed messages). To provide this the configuration for the ErrorHandler has been extracted and assembled in the ErrorHandlerConfig XBean. * In my opinion the error handler hook and the handlers strategy should be separated. I am involved in a migration project (from a commercial EAI solution to open source). In the current EAI system an error handler is always implemented. We want to migrate this solution that is based on a set of database stored rules. I think there can be a lot of error handler strategy implementations. One default handler can be an implementation as discussed before. * At this time i am using my own extension of the JBIContainer. This extension registeres an ErrorEventListener as EventListener by default. I have not found a way to configure event listeners in the deployment descriptor. The ErrorHandler is a attribute of the extended container (the getter/setter methods are using the ErrorEventListerners 'errorHandler' attribute). Have you tried something like: sm:container id=jbi embedded=true sm:listeners bean class= / /sm:listeners It works. Best regards, Ralf Wunsch -- View this message in context: http://www.nabble.com/Declarative-Exception-Handling-in-ServiceMix-tf2161788.html#a6661952 Sent from the ServiceMix - Dev mailing list archive at Nabble.com. -- Cheers, Guillaume Nodet
Re: Declarative Exception Handling in ServiceMix
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
Re: Declarative Exception Handling in ServiceMix
You could try to take the EIP WireTap pattern as a basis, or the StaticRoutingSlip. I think of the following pattern: * the pattern receive an exchange A * it copy it and send it to the main target B * if B answers with a DONE, send back DONE to A * if B answers with ACTIVE (out or fault), send back to A * if B answers with ERROR, resend the same exchange to C * send back the answer from C to A I' m not quite sure if we should support some routing here on the Exception reported by B. I guess it should be easy to define sereral classes/target combinations, and the first one that match (the exception inherit the configured one) wins. It would give something like eip:error-handler service=... endpoint=... eip:target eip:exchange-target service=test:xpathSplitter / /eip:target eip:error class=java.io.IOException eip:exchange-target service=test:flow1 / /eip:error eip:error eip:exchange-target service=test:default / /eip:error /eip:error-handler This example would route all IOException to flow1, and other exceptions to default. I also think that the exception should be put in a property on the new exchange, so that the target could use if if necessary. Makes sense ? On 8/31/06, jpuro [EMAIL PROTECTED] wrote: 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
Re: Declarative Exception Handling in ServiceMix
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
Re: Declarative Exception Handling in ServiceMix
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
Declarative Exception Handling in ServiceMix
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.
