Announcement Announcement Module
Collapse
No announcement yet.
Exception handling with ChannelInterceptor Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Exception handling with ChannelInterceptor

    Hi,

    I would like to create a pollable channel with an integrated ChannelInterceptor. When a message has been succesfully processed, I need to update a status flag in the database. When an exception was thrown, the status needs to be set to an error flag. What is the best way forward for this scenario?

    My backing DAO has these methods
    public MyObject getNextUnpprocessed()...
    public void updateStatus(MyObject obj, String status)...

    My first idea was to implement a PollableChannel and ChannelInterceptor at the same time, but is this a good idea?

    How are 'normal' channels warned that something down tthe chain has gone wrong?

    Regards,
    Leen

  • #2
    My initial reaction is that this logic shouldn't be in a channel but rather a handler (or most likely a service object referenced by a service-activator). Could you explain the larger context of the use-case, so that I can understand why you think it should be implemented in the channel?

    Comment


    • #3
      Hi Mark,

      I have a DAO service with basically two functions:
      public MyObject getNext()
      public void updateStatus(MyObject obj, String statusFlag)


      The getNext() functions can easily be seen as a PollableChannel, so that makes sence (to me at least :-) ), so I made a wrapper around the DAO implementing the DAO.

      The service using the DAO runs inside OSGI, and I would like to hide as much of the implementation specifics of the DAO from the service using it. Spring integration looks a good solutions for that.

      The only thing that bugs me is that the status flag of a processed MyObject should be set to Processed/Error after it has been processed. I looked at ChannelInterceptor, but it looks quite odd for this use case.

      Regards,
      Leen

      Comment


      • #4
        One quick idea... have you considered an <inbound-channel-adapter /> for invoking the getNext() method?

        Comment


        • #5
          There is an error handling sample in our sandbox. I haven't looked at it for a while, so you might need to jump some hoops to make it compile again. I am not sure where the exception is thrown, but it seems to me that it would end up on the error channel and you could just route error messages back to the updateStatus method.

          Or did I miss something?

          Comment

          Working...
          X