-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Short-circuit methods for lambdas from annotation #2823
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Short-circuit methods for lambdas from annotation #2823
Conversation
If the solution is OK, I'll go ahead with other Messaging annotations. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! Just one comment.
|
||
Class<?> expectedPayloadType = methodReturnType.getGeneric(0).toClass(); | ||
serviceActivator = new ServiceActivatingHandler( | ||
new LambdaMessageProcessor(target, expectedPayloadType)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you need to check for wildcard generic types here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure what you mean, but with the methodReturnType.getGeneric(0).toClass()
it returns an Object
class for a Consumer<?>
. So, I think we are good.
When we have a `@ServiceActivator` or any other messaging annotations on `Function` or `Consumer` `@Bean`s, there is a restriction when we can't use lambdas because of target method argument type erasure in Java. * Use a `@Bean` method return to determine the target function argument type and wrap the call into the `LambdaMessageProcessor`. In this case we call the target method directly after possible payload conversion according expected generic type for `Function` or `Consumer`. There is just no reason to go a `MessagingMethodInvokerHelper` route for this lambda variants * Apply the short-circuit algorithm for Kotlin lambdas as well * Make some refactoring and improvements to `ClassUtils` if favor or similar API in the SF `ClassUtils` * Fix `No beanFactory` warning for the `ExpressionCommandMessageProcessor`
d49d6d7
to
0dbdf0e
Compare
Ready for review. Thanks |
|
Pushed the fix. Thank you for pointing that out! There is an |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a couple of minor issues.
@@ -510,9 +515,26 @@ protected void checkMessageHandlerAttributes(String handlerBeanName, List<Annota | |||
} | |||
} | |||
|
|||
protected boolean resolveAttributeToBoolean(String requiresReply) { | |||
return Boolean.parseBoolean(this.beanFactory.resolveEmbeddedValue(requiresReply)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds like a generic method name, but specific parameter name. String attribute
?
@@ -3118,7 +3122,8 @@ protected StandardIntegrationFlow get() { | |||
if (this.integrationFlow == null) { | |||
if (this.currentMessageChannel instanceof FixedSubscriberChannelPrototype) { | |||
throw new BeanCreationException("The 'currentMessageChannel' (" + this.currentMessageChannel | |||
+ ") is a prototype for 'FixedSubscriberChannel' which can't be created without 'MessageHandler' " | |||
+ ") is a prototype for 'FixedSubscriberChannel' which can't be created without " + | |||
"'MessageHandler' " |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
without a 'MessageHandler'.
* Fix typo in the exception message for `IntegrationFlowDefinition.get()`
|
does exactly opposite one
When we have a
@ServiceActivator
or any other messaging annotationson
Function
orConsumer
@Bean
s, there is a restriction when wecan't use lambdas because of target method argument type erasure in Java.
@Bean
method return to determine the target function argumenttype and wrap the call into the
LambdaMessageProcessor
.In this case we call the target method directly after possible payload
conversion according expected generic type for
Function
orConsumer
.There is just no reason to go a
MessagingMethodInvokerHelper
routefor this lambda variants