Announcement Announcement Module
No announcement yet.
Header Enricher & Groovy Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Header Enricher & Groovy

    Hello, Mark, Oleg & Dave

    You all are authors of integration with Groovy.
    So, here's my wish to improve that solution.
    Why not implement an evalutaion of value for one header through <groovy:script>?
    You already support that through SpEL.
    But SpEL is single line script, and in my case it doesn't solve my problem.
    And further I don't see reason to write separate Java-class or to move solving of my task to Transformer.
    My sample is:
    1. Payload is XML
    2. I have a delayer
    3. I have to set a header for delayer
    4. The value for this header is Date based on content of payload
    5. So, I evalute xPath -> parse result to Date -> add delay from SpringContext -> and put final Date to header for delayer.

    I think it is a reason where we can use short Groovy scripts.
    I see no reason to write a complete transformer for setting value of only one header.

    Thanks in advance


  • #2
    So, colleagues, because you do not respond to my post, I tried to implement this decision by ьнself.
    The fact that I came out in the attachment.
    I marked my changes as TODO
    Here is an example of usage:
    HTML Code:
                <header name="logId" ref="logRequestResponseAction" method="log"/>
                <header name="TEST_HEADER">
                                new XmlParser().parseText(headers.requestXml).with {
                                    return new Date(Date.parse("yyyy-MM-dd'T'HH:mm:ss", headerData.messageDescription.requestDate.text()).time + 300 * 1000)
    I think this functionality could be useful.

    Best wishes.


    • #3
      Thanks for the code. It's probably not ideal to force spring-integration-core to have a new dependency that way, but there might be other ways to do the same thing. This already works out of the box, for instance, and it isn't a lot more verbose than your example:

                  <header name="logId" ref="logRequestResponseAction" method="log"/>
                  <header name="TEST_HEADER" ref="enricher" method="enrich"/>
      	<lang:groovy id="enricher">
      			class Enricher {
      				def enrich(Map headers) {
                                  new XmlParser().parseText(headers.requestXml).with {
                                      return new Date(Date.parse("yyyy-MM-dd'T'HH:mm:ss", headersData.messageDescription.requestDate.text()).time + 300 * 1000)
      Last edited by Dave Syer; Apr 28th, 2011, 09:58 AM. Reason: spelling


      • #4
        Artem, sorry for late reply. Some of us were traveling


        I agree we don't want to have core depend on Groovy, but it seems like in his case its just an implementation of MessageProcessor strategy and a minor change to schema.
        Let me try to see if I can rework it a bit.

        Artem, meanwhile can you open up a feature request so we can incorporate these comments in it.


        • #5
          Hello, guys!

          I'm glad to see (read) you.

          Depending on what you say? Sorry for my mistakes. But there are dependency only in unnecessary imports in my code in HeaderEnricher.
          In my maven project exists depency only from artifact spring-integration-core right now

          I tried to reuse code that you already have.

          And it is my comment about Dave's sample:
          In your solution in SI we can write some short groovy script in Message context. Your sample is full defined class. If I then want more scripts like my task I'll have to write a lot of code. And in the end I decide to move it all into a single class.

          Oleg, what do you mean about "open up a feature request"? Should I open issue in JIRA?

          Thank you for your work


          • #6
            Yes, as 'New Feature" in JIRA


            • #7
              IMHO it should be treated the same as:
              <int:header name="TEST_HEADER">
                          <bean class="org.Foo"/>
              Basically your inner-bean support instead of the 'ref'


              • #8
                Ok, I have it working now with the <bean> and <script> without core being dependent on groovy and/or things like this:
                DomUtils.getChildElementsByTagName(headerElement, "script");
                Let us know when you open a JIRA


                • #9
                  Thank you, Oleg, for your enthusiasm and eagerness to work .
                  I will open issue tomorrow in our time - you'll even sleep.

                  Thank you again



                  • #10
                    I added JIRA "New Feature":


                    • #11
                      Oleg, thanks for your idel work!
                      Your solution looks very cool & vary simple.
                      Live & learn.
                      When will release 2.0.4?

                      So, Oleg, what about the annotation on method for header value like @Transformer ?

                      Last edited by Artem Bilan; May 4th, 2011, 07:15 AM.


                      • #12
                        Should be shortly (this week)