spring-projectsGH-3807: Necessity of KafkaHandler on single method class

[chickenchickenlove]

Fixes: #3807
Issue link: #3807

From now on, the single public method without method-level @KafkaHandler, @KafkaListener in class which has class-level @KafkaListener will be registered as MethodKafkaListenerEndpoint so that it consumes messages.

[artembilan]

This is very close to the merge phase.
Please, consider to mention this feature in the class-level-kafkalistener.adoc and whats-new.adoc.

Thanks

[artembilan]

This is not OK.
I'm really against any blocking in the tests for nothing.
I mean this always going to add up 10 seconds to the whole test suite execution.
Now imaging we have like 3000 tests in the project and every one would contribute some delay.

I believe the configuration when we have ambiguity with several public methods has to be reject with an IllegalStateException.
No silent ignoring to make am impression that my configuration is OK.

[chickenchickenlove]

@artembilan thanks for your comments. 🙇‍♂️

This is not OK.
I'm really against any blocking in the tests for nothing.
I mean this always going to add up 10 seconds to the whole test suite execution.
Now imaging we have like 3000 tests in the project and every one would contribute some delay.

I agree.
I will remove this case from test codes.

I believe the configuration when we have ambiguity with several public methods has to be reject with an IllegalStateException.

I understand your point clearly.
However, The important thing is that the changes I made in this PR are not related to the case where there are multiple public methods.
So we don't need to consider ambiguous conditions because in that case any public method will not be registered as kafka listeners.

if (hasClassLevelListeners) {
  if (methodsWithHandler.isEmpty() && publicMethods.size() == 1 && !hasMethodLevelListeners) {
    // added this time.
  }
  else {
    // original	
  }
}

I think we would be better not to throw an error if there are several public methods when there is no @KafkaHandler method.
This is because after registering the class as a bean using @KafkaListener, there might be cases where other beans inject it and call its public methods. For example, getter methods.
If there are already users using it that way, it would be difficult to ensure backward compatibility.

@KafkaListener
class MyTakser {
  
  // This method is for @KafkaHandler implicitly.
  public void listen (String message) {
    // do something with kafka messages.
  }

  // This method is not for @KafkaHandler.
  public void getCurrentState() {
    // return current state
  }
  
  ...
}

IMHO, If we should something to do for this, I think it would be better to notify by using warning log.
For example,

The bean {BEAN_NAME} which has @KafkaListener is registered without a proper listener method.

WDYT?

[artembilan]

I think I see the picture better now. What if our class is extended and new methods appear there? Which one to choose from hierarchy then?

I am sorry to say that , but I feel more like better to leave it as is and rely only on the @KafkaHandler presence .

The issue simply could be turned into docs explaining why we require this or other annotation. We really cannot predict what purpose of the method is, so being explicit is much better, than trying to come up with other restrictions. I have totally ignored the fact that class could be extended 🤦.

And between us: I’m not a fun of annotations in Java. 😉

Still, that is my opinion on the problem of this issue, so I’m opened for other arguments to continue your effort with the code.

CC @sobychacko