Announcement Announcement Module
No announcement yet.
groovy:script with customizer bug? Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • groovy:script with customizer bug?

    Hello, Mark & Oleg,

    I've tried to use the new implementation of GroovyScriptExecuting when my script was inline and i've added to him the customizer.

    In my case the script is very simple: it invokes the hibernate named query with parameter from payload and transform result to new outbound payload.

    This is sample:

    HTML Code:
     <service-activator input-channel="input" output-channel="response">
            <groovy:script customizer="hibernateSessionGroovyObjectCustomizer">
                    import static org.hibernate.Hibernate.INTEGER as Hibernate_INTEGER
                    def result = hibernateSession.getNamedQuery('getInfo')
                                            .setParameter('pageNo', payload != '' ? payload.pageNo : null, Hibernate_INTEGER)
                    if (result.empty) return ''
                    def firstRecord = result[0]
                    return new ResData(
                        records: result,
                        nextPageNo: firstRecord.nextPageNo
    So, I added the Hibernate Session to Script context from SpringContext as Bean via implementation of GroovyObjectCustomizer.

    When I received the Exception in script evaluation, in my case it was an SqlException during Hibernate execution, I found the problem in
    org.springframework.integration.util.MessagingMeth odInvokerHelper.processInternal, where the candidates for my payload are processMessage from AbstractScriptExecutingMessageProcessor and GroovyScriptExecutingMessageProcessor.setCustomize r
    So, When first called processMessage, and an Exception occurs, then called setCustomizer with my payload(!!!).
    At the end I receive the Exception of invoking method with invalid arguments.

    I'm confused. Whether this mechanism generally works?
    Why candidate method attempts to be selected by type Message when I have clearly come pyaload?
    Thoroughly investigate the problem I can't: too much complicated architecture of the project.
    Oh, and the question is not on the topic: why not use the tag variable along with inline script, anyway it all comes down ScriptSource?

    Thank you,
    Artem Bilan
    Last edited by Artem Bilan; Feb 22nd, 2011, 10:53 AM.

  • #2

    I am looking into this. It seem like we have a bug in a way that we did not restrict you to s ingle <script> sub-element per service-activator. In other words what you showing should not work, but we should have been more proactive in disallowing multiple <script> elements.

    Feel free to open a JIRA issue for it.


    • #3
      So, I've solved the problem: I changed the enclosed service-activator to transformer and i've got List<HandlerMethod> candidates with only one method - processMessage from AbstractScriptExecutingMessageProcessor.

      And as I noticed that when I do not use сustomizer then сandidates appear in a different sequence, but also caused the two together with both Exseptions, that's just right to me comes first.


      • #4
        Thank you, Oleg for your response.
        But it was my copy-paste mistake. I edited my sample.
        And the prombel is open.


        • #5

          I guess our post crossed, so please read my reply and alos read my comments in the JIRA when you asked the questions earlier


          • #6
            Ok, Oleg
            I understand your answers.
            But I have another question: what is scenario when I need refreshable scripts?
            And other question: where should I put the files be able to use them as refreshable?

            In my case my application is deployed in cluster.

            Thank you


            • #7
              what is scenario when I need refreshable scripts?
              Any time you would want to change the logic without replacing/rebuilding the java code which is quite typical in the highly dynamic environments. This is one of the motivations to use scripts in the first place.

              where should I put the files be able to use them as refreshable?
              Anywhere you want, but if you want since it uses the same Spring Resource abstraction as everything else (e.g., classpath:..., file:... etc.)
              <transformer input-channel="someChannel">
              		<groovy:script refresh-check-delay="10000" location="file:foo/bar/MyTransformer.groovy"/>
              In the above, the state of the script will be cached for 10 seconds and then it will check if it was modified where if it was it will initialize a new version without stopping your application.