Cutsom MessageContextBindingCustomizer

[jbaruch]

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,
Baruch.

[Mark Fisher]

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. "@bean.foo(payload, headers.bar)").

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.

[jbaruch]

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!
Baruch

[jbaruch]

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.

[Mark Fisher]

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.

Thanks,
Mark

[jbaruch]

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.
https://jira.springframework.org/browse/INT-1727

[Mark Fisher]

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

[jbaruch]

Those are great news!