Skip to content

Conversation

mjd507
Copy link
Contributor

@mjd507 mjd507 commented Aug 29, 2025

Related to: #10083

MessageProcessorMessageSource now provides a fake message to the underlying messageProcessor since the contract requires.

add @Nullable on CheckedCallable.call(), since in LockRequestHandlerAdvice.doInvoke(), there is a lambda ExecutionCallback::execute which will be running inside the call(), and its Nullable.

Related to: spring-projects#10083

`MessageProcessorMessageSource` now provides a fake message to the underlying messageProcessor since the contract requires.

add `@Nullable` on `CheckedCallable.call()`, since in `LockRequestHandlerAdvice.doInvoke()`, there is a lambda `ExecutionCallback::execute` which will be running inside the `call()`, and its Nullable.

Signed-off-by: Jiandong Ma <[email protected]>
Copy link
Member

@artembilan artembilan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a lot, but great.
Let's see if we can manage such a big review as well!

…r()`

revert `@Nullable` on `CheckedCallable.call()` as it is nullable from generic type definition, for `LockRequestHandlerAdvice`, add NullAway since `ExecutionCallback.execute` is Nullable as well.

move fakeMessage to a static final constant in `MessageProcessorMessageSource`

add NullAway on `RequestHandlerRetryAdvice.recoveryCallback.recover()`, need rework on retry component

use `Map.computeIfAbsent` in `PayloadsArgumentResolver` and `PayloadExpressionArgumentResolver`

add more detailed reason (critical path, dataflow analysis) on NullAway method.

Signed-off-by: Jiandong Ma <[email protected]>
@mjd507
Copy link
Contributor Author

mjd507 commented Aug 29, 2025

ok, I have addressed most review comments, two of them are not revised due to it may take me more time.

  1. LockRequestHandlerAdvice#doInvoke , I add NullAway for now, this.lockRegistry.<@Nullable Object, RuntimeException>executeLocked seems not working.
  2. I did not remove componentType and setter method in ExpressionEvaluatingMessageHandler & MethodInvokingMessageHandler , unit test looks covers that.

@artembilan happy Friday, if any new reviews I will solve on next week.
if hurry, you always can take from where it is, and help me fix that.

@@ -35,8 +35,7 @@ public class ExpressionEvaluatingMessageHandler extends AbstractMessageHandler {

private final ExpressionEvaluatingMessageProcessor<Void> processor;

@SuppressWarnings("NullAway.Init")
private String componentType;
private String componentType = "expression-evaluating-handler";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, I mean remove setComponentType() at all.
This contract is not meant to be overridden by end-user.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, I tried that, unit test failed a lot, there it will call setComponentType()

@@ -36,8 +36,7 @@ public class MethodInvokingMessageHandler extends AbstractMessageHandler impleme

private final MethodInvokingMessageProcessor<Object> processor;

@SuppressWarnings("NullAway.Init")
private String componentType;
private String componentType = "method-invoking-handler";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

DITTO

@@ -59,8 +59,9 @@ public ErrorMessageSendingRecoverer() {
* The {@link DefaultErrorMessageStrategy} is used for building an error message to publish.
* @param channel the message channel to publish error messages on recovery action.
*/
@SuppressWarnings("this-escape")
public ErrorMessageSendingRecoverer(@Nullable MessageChannel channel) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This must not be null.
Looks like you have missed some parts of my previous explanation.

@@ -74,7 +75,7 @@ public ErrorMessageSendingRecoverer(@Nullable MessageChannel channel) {
* @since 4.3.10
*/
@SuppressWarnings("this-escape")
public ErrorMessageSendingRecoverer(@Nullable MessageChannel channel, @Nullable ErrorMessageStrategy errorMessageStrategy) {
public ErrorMessageSendingRecoverer(MessageChannel channel, ErrorMessageStrategy errorMessageStrategy) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

According to this our contract that ternary operator in the setErrorMessageStrategy() call is redundant.

@@ -152,6 +152,7 @@ protected void onInit() {
this.evaluationContext = ExpressionUtils.createStandardEvaluationContext(getBeanFactory());
}

@SuppressWarnings("NullAway") // CheckedCallable.call() is nullable
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still have doubts in this.
Will take a look one more time when the rest of concerns are addressed.

@artembilan
Copy link
Member

if hurry, you always can take from where it is, and help me fix that.

Sounds good!
So, I'm taking it from here since looks like we have some problems which better to solve sooner.

Pulling your branch locally for clean up and merge.

Thank you!

@artembilan
Copy link
Member

Fixed via: a167170.
And subsequent cleanup and improvements: 31a7dd4

Thank you again!

@artembilan artembilan closed this Aug 29, 2025
@artembilan artembilan added this to the 7.0.0-M3 milestone Aug 29, 2025
@mjd507 mjd507 deleted the jspecify-core-handler branch August 29, 2025 23:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants