Announcement Announcement Module
Collapse
No announcement yet.
So what about handling of null payloads? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • So what about handling of null payloads?

    I'm using Spring Integration 1.0.3. This is my concrete case:
    Code:
    <chain input-channel="someChannel">
        <transformer ref="transformer1"/>
        <service-activator ref="someService" method="someMethod"/>
        <transformer ref="transformer2"/>
    </chain>
    Scenario:
    My service-activator calls a service I do not control (someService.someMethod). This service returns null. Then Spring Integration simply hangs, or at least give no reply. "transformer2" never get invoked.

    I've debugged the problem to be in class:
    Code:
    org.springframework.integration.handler.AbstractReplyProducingMessageHandler.handleMessageInternal()
    If the payload is null then handleMessageInternal() simply returns silently.

    So what about handling of null payloads? How can I solve my problem without major hackery?
    Last edited by pompiuses; Feb 26th, 2010, 01:30 PM.

  • #2
    If Spring Integration blocks the invoking thread indefinitely that would be a bug.

    Not invoking transformer2 in case someService returns null is by design.

    You can solve your problem by not returning null if there is something to do for transformer2. If there is nothing to transform you should not be dependent on a transformer2 invocation, in particular since you're not expecting any output from the chain, or did I miss something?

    Comment


    • #3
      Originally posted by iwein View Post
      If Spring Integration blocks the invoking thread indefinitely that would be a bug.

      Not invoking transformer2 in case someService returns null is by design.

      You can solve your problem by not returning null if there is something to do for transformer2. If there is nothing to transform you should not be dependent on a transformer2 invocation, in particular since you're not expecting any output from the chain, or did I miss something?
      I'm using a GatewayProxyFactoryBean in front of my Spring Integration channel pipeline. When the null payload occurs Spring Integration never proceed to exit the channel. That means that whoever invoked my proxy interface won't get an answer, and will simply hang.

      However looking through the source code I see that class AbstractReplyProducingMessageHandler has a property "requiresReply" which will cause an exception to be thrown when receiving a null payload. The problem is that I can't find a way to set this property in the XML namespace. Any tip?

      The problem with never returning null is that I have to refactor many of the services in my legacy code. Why should I be forced to refactor code which have been running stable for years just to please Spring Integration? This is obviously something I don't want to do.

      I also use the Spring Integration XmlPayloadUnmarshallingTransformer, like this:
      Code:
      <si-xml:unmarshalling-transformer input-channel="freeTextSearchResponseChannel" 
      unmarshaller="freeTextSearchUnmarshaller"/>
      This unmarshaller does indeed return null if the given XML is i.e. invalid, which again will cause Spring Integration to get upset if put in the middle of a message channel. I'm able to get around this by implementing my own unmarshaller and returning various null objects depending on the scenario, but it's something I should not be forced to do.

      My life would be a lot easier if Spring Integration would support null payloads. Mule does this. If not it looks like I'll be forced to put wrappers around most of my services and third party APIs, which is poor design.
      Last edited by pompiuses; Feb 27th, 2010, 01:54 PM.

      Comment


      • #4
        Point taken, I can see that Spring Integration is causing some friction for you. You could create an issue for this in JIRA, then people could vote for it.

        Comment


        • #5
          Created issue:
          https://jira.springsource.org/browse/INT-997

          Comment

          Working...
          X