You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by jpuro <jp...@sterlingtesting.com> on 2006/08/25 00:49:48 UTC
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.
Re: Declarative Exception Handling in ServiceMix
Posted by Bruce Snyder <br...@gmail.com>.
On Tue, May 20, 2008 at 6:44 AM, pratibhaG <pr...@in2m.com> wrote:
>
> Hi,
> Has anybody got success in building this kind of component which will handle
> all the exceptions?
> I am working on same problem. please help.
Nothing has been implemented for this yet. The closest solution might
be to use the servicemix-camel component and Camel's errorHandler()
method:
http://activemq.apache.org/camel/error-handler.html
And that would still require you to write your own Java code to handle
errors (i.e., calling other components, etc.).
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
Apache ActiveMQ - http://activemq.org/
Apache Camel - http://activemq.org/camel/
Apache ServiceMix - http://servicemix.org/
Apache Geronimo - http://geronimo.apache.org/
Blog: http://bruceblog.org/
Re: Declarative Exception Handling in ServiceMix
Posted by pratibhaG <pr...@in2m.com>.
Hi,
Has anybody got success in building this kind of component which will handle
all the exceptions?
I am working on same problem. please help.
Thanks,
Pratibha
--
View this message in context: http://www.nabble.com/Declarative-Exception-Handling-in-ServiceMix-tp5974450p17339450.html
Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: Declarative Exception Handling in ServiceMix
Posted by jpuro <jp...@sterlingtesting.com>.
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.
Re: Declarative Exception Handling in ServiceMix
Posted by Guillaume Nodet <gn...@gmail.com>.
On 10/5/06, Ralf Wunsch <r....@ist-dresden.de> 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
Posted by Ralf Wunsch <r....@ist-dresden.de>.
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#a6661952
Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: Declarative Exception Handling in ServiceMix
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <r....@ist-dresden.de> 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...
> >
>
> >
>
> > <bean id="errorHandler"
> > class="de.eval.eai.error.DefaultErrorHandler">
> > </bean>
> > ...
> > <bean id="errorHandlerConfig"
> > class="de.eval.eai.error.ErrorHandlerConfig">
> > <property name="shutdownOnFault" value="true" />
> > <property name="rollbackOnFault" value="false" />
> > </bean>
> > ...
> > <test:container id="jbi"
> > useMBeanServer="true"
> > createMBeanServer="false"
> > dumpStats="true"
> > statsInterval="10"
> > errorHandler="#errorHandler"
> > errorHandlerConfig="#errorHandlerConfig">
> > ...
> > <sm:activationSpecs>
> > ...
> > <sm:activationSpec componentName="errorHandler">
> > <sm:component>
> > <eai:component>
> > <eai:endpoints>
> > <eai:errorHandler service="errorHandler"
> > endpoint="endpoint">
> > <eai:target>
> > <eai:exchange-target service="transformer" />
> > </eai:target>
> > <eai:disqualifyTarget>
> > <eai:exchange-target service="failedQueue" />
> > </eai:disqualifyTarget>
> > <eai:errorTarget>
> > <eai:exchange-target service="errorQueue" />
> > </eai:errorTarget>
> > <eai:faultTarget>
> > <eai:exchange-target service="faultQueue" />
> > </eai:faultTarget>
> > <property name="shutdownOnFault" value="true" />
> > <property name="rollbackOnFault" value="false" />
> > </eai:errorHandler>
> > </eai:endpoints>
> > </eai:component>
> > </sm:component>
> > </sm:activationSpec>
> > ...
>
> >
>
> >
>
> > 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
Declarative Exception Handling in ServiceMix
Posted by Ralf Wunsch <r....@ist-dresden.de>.
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...
>
>
> <bean id="errorHandler"
> class="de.eval.eai.error.DefaultErrorHandler">
> </bean>
> ...
> <bean id="errorHandlerConfig"
> class="de.eval.eai.error.ErrorHandlerConfig">
> <property name="shutdownOnFault" value="true" />
> <property name="rollbackOnFault" value="false" />
> </bean>
> ...
> <test:container id="jbi"
> useMBeanServer="true"
> createMBeanServer="false"
> dumpStats="true"
> statsInterval="10"
> errorHandler="#errorHandler"
> errorHandlerConfig="#errorHandlerConfig">
> ...
> <sm:activationSpecs>
> ...
> <sm:activationSpec componentName="errorHandler">
> <sm:component>
> <eai:component>
> <eai:endpoints>
> <eai:errorHandler service="errorHandler"
> endpoint="endpoint">
> <eai:target>
> <eai:exchange-target service="transformer" />
> </eai:target>
> <eai:disqualifyTarget>
> <eai:exchange-target service="failedQueue" />
> </eai:disqualifyTarget>
> <eai:errorTarget>
> <eai:exchange-target service="errorQueue" />
> </eai:errorTarget>
> <eai:faultTarget>
> <eai:exchange-target service="faultQueue" />
> </eai:faultTarget>
> <property name="shutdownOnFault" value="true" />
> <property name="rollbackOnFault" value="false" />
> </eai:errorHandler>
> </eai:endpoints>
> </eai:component>
> </sm:component>
> </sm:activationSpec>
> ...
>
>
> 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
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <jp...@sterlingtesting.com> 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 <gn...@gmail.com> 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 <jp...@sterlingtesting.com> 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.
>
>
--
Cheers,
Guillaume Nodet
Re: Declarative Exception Handling in ServiceMix
Posted by jpuro <jp...@sterlingtesting.com>.
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 <gn...@gmail.com> 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 <jp...@sterlingtesting.com> 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.
Re: Declarative Exception Handling in ServiceMix
Posted by jpuro <jp...@sterlingtesting.com>.
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 <gn...@gmail.com> 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 <jp...@sterlingtesting.com> 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.
Re: Declarative Exception Handling in ServiceMix
Posted by Philip Dodds <ph...@gmail.com>.
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 <gn...@gmail.com> 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 <jp...@sterlingtesting.com> 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
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <jp...@sterlingtesting.com> 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