Announcement Announcement Module
No announcement yet.
Cutsom MessageContextBindingCustomizer Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Cutsom MessageContextBindingCustomizer

    Hi, folks!
    I am using groovy script as service-activator and want to customize it (basically, inject more beans into it).
    The "groovy:script" tag inside service-activator creates bean of class GroovyScriptExecutingMessageProcessor, which does not expose its GroovyObjectCustomizer. Instead, it hard-codes it to MessageContextBindingCustomizer:
    public class GroovyScriptExecutingMessageProcessor extends AbstractScriptExecutingMessageProcessor<Object> {
    	private final MessageContextBindingCustomizer customizer = new MessageContextBindingCustomizer();
    That's not like you, guys! What gives?

    Thanks in advance for your advice,

  • #2
    Have you considered just using Spring's "regular" support for Groovy? In other words, use the 'lang' namespace so that your Groovy script is essentially a "bean" within the context. It is then eligible for dependency injection, etc. It would then be available via the service-activator's "ref" attribute or using SpEL's bean resolution (e.g. ",").

    The support for direct invocation of Groovy scripts in Spring Integration is really intended for cases where the only context needed is the Message itself, and therefore a simple script can be used as opposed to a "bean" whose properties can be injected.


    • #3
      Mark, thanks for the help! Using regular Groovy bean will sure work.

      Two issues with it:
      1. Minor - Embedded element is more concise syntax.
      2. Major - Groovy code declared with lang:groovy are classes, while groovy code declared with groovy:script are scripts! The later is the one I need - no classes, no interfaces, no methods. Just a script file with some kind of mini-dsl that I want to inject using my own Customizer. Good analogy here is build.gradle - it is Groovy, but it is not Groovy class from user perspective, is it? That's more or less the use case - script for someone who doesn't know Groovy and/or Java and/or OOP.

      Thanks again!
      Last edited by jbaruch; Dec 30th, 2010, 03:04 AM. Reason: rephrasing after taking a look


      • #4
        In case you'll decide you want this extension, here's what I did:
        1. New attribute 'customizer-ref' in 'groovy' schema
        2. GroovyScriptParser adds another constructor argument to the beanDefenition of GroovyScriptExecutingMessageProcessor
        3. In the constructor MessageContextBindingCustomizer is wrapped with new class, ExtendedMessageContextBindingCustomizer which delegates to MessageContextBindingCustomizer and invokes the customize() on the new customizer
        Patch attached.


        • #5
          Thanks Baruch. That does indeed seem like a useful extension point. Could you please open a JIRA issue and point to this forum thread so we can get it on the roadmap?

          Also, for just a bit of background, our original intent was simply to take advantage of the customizer hook ourselves as a way to populate the script bindings from the Message at runtime. So, the reason it was not exposed via setters is that it was not as much a "strategy" as an internal implementation detail. However, your use case makes it clear that there is some value in exposing it as a strategy after all.



          • #6
            I glad to hear you liked the idea. Now I have locally patched version of Spring Integration, and I hate the fact is it patched.

            Here is the JIRA issue, fingers crossed to be implemented ASAP.


            • #7
              Thanks for creating the issue. I've set the target version to 2.0.2 (our next release).


              • #8
                Those are great news!