Unmanaged beans w/ AmazonS3MessageHandler

[chadmaughan]

Hi @garyrussell and @artembilan

While using AmazonS3MessageHandler in a Spring XD module, I'm running into exceptions.

In AmazonS3MessageHandler.handleMessageInternal(), the ExpressionEvaluatingMessageProcessor.processMessage() called here expects a BeanFactory. Because this is not a managed bean see creation here you get a RuntimeException complaining of "No beanfactory".

The same can also occur with AmazonS3MessageHandler.setFileNameGenerator(), however setters exist to provide a managed bean.

I was thinking instead of creating the ExpressionEvaluatingMessageProcessor, it could be passed in.

I'd be happy to issue a PR. What do you think?

I also have a sample XD module that exhibits the behavior if you'd like me to share.

Thanks!

[chadmaughan]

Here's a full stacktrace. Thanks!

java.lang.RuntimeException: No beanfactory
    at org.springframework.integration.expression.ExpressionUtils.createStandardEvaluationContext(ExpressionUtils.java:79)
    at org.springframework.integration.util.AbstractExpressionEvaluator.getEvaluationContext(AbstractExpressionEvaluator.java:114)
    at org.springframework.integration.util.AbstractExpressionEvaluator.getEvaluationContext(AbstractExpressionEvaluator.java:100)
    at org.springframework.integration.util.AbstractExpressionEvaluator.evaluateExpression(AbstractExpressionEvaluator.java:164)
    at org.springframework.integration.util.AbstractExpressionEvaluator.evaluateExpression(AbstractExpressionEvaluator.java:123)
    at org.springframework.integration.handler.ExpressionEvaluatingMessageProcessor.processMessage(ExpressionEvaluatingMessageProcessor.java:72)
    at org.springframework.integration.aws.s3.AmazonS3MessageHandler.handleMessageInternal(AmazonS3MessageHandler.java:120)
    at org.springframework.integration.handler.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:78)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:483)
    at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
    at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:190)
    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157)
    at org.springframework.integration.monitor.SimpleMessageHandlerMetrics.handleMessage(SimpleMessageHandlerMetrics.java:107)
    at org.springframework.integration.monitor.SimpleMessageHandlerMetrics.invoke(SimpleMessageHandlerMetrics.java:87)
    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
    at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:207)
    at com.sun.proxy.$Proxy131.handleMessage(Unknown Source)

[artembilan]

Hi, @chadmaughan !

Thank you for pointing this out!
Yes, it's definitely a bug, although in face of Spring Integration since 4.0.

To fix it (as you mention through the PR) take a look, please, to the similar component FileWritingMessageHandler.

The point to pay attention is:

if (!this.fileNameGeneratorSet && this.fileNameGenerator instanceof BeanFactoryAware) {
            ((BeanFactoryAware) this.fileNameGenerator).setBeanFactory(this.getBeanFactory());
}

And populate the same getBeanFactory() to that ExpressionEvaluatingMessageProcessor and call its afterPropertiesSet().

From other side it isn't covered by tests, hence we've caught it already...

Looking forward for the contribution!