Skip to content
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

GH-1817: Allow Annotation Attribute Modification #1818

Merged
merged 5 commits into from
Jun 4, 2021

Conversation

garyrussell
Copy link
Contributor

Resolves #1817

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.

Here is some review, but I'm OK if you convince me that the fix must be really your way.

Thanks

? ((Class<?>) element).getSimpleName()
: ((Method) element).getDeclaringClass().getSimpleName()
+ "." + ((Method) element).getName()));
return AnnotationUtils.synthesizeAnnotation(attrs, KafkaListener.class, null);
Copy link
Member

Choose a reason for hiding this comment

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

Let's revise this solution and push such a "hard" logic back to the framework!

I guess the same could be done with that AnnotationUtils.getAnnotationAttributes(ann) in the beginning.

I mean the contract of the enhancer would be like BiFunction<Map<String, Object>, AnnotatedElement, Map<String, Object>> - and the rest we would do internal ourselves!

Also: the KafkaListenerAnnotationBeanPostProcessor is a single instance in the application context.
Wouldn't it be easier for end-user just to provide such an enhancer bean and that's it. I mean it might have to be some more specific type, rather then just BiFunction. Although it might extend that interface anyway.
Then the framework would just take such a bean from the application context instead of requiring "hard core" for the whole KafkaListenerAnnotationBeanPostProcessor definition when we need just only a natural DI behavior with user-provided strategy in the application context.

Does it make sense?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good points - will rework.

* @since 2.7.2
*
*/
public interface AnnotationEnhancer extends BiFunction<KafkaListener, AnnotatedElement, KafkaListener> {
Copy link
Member

Choose a reason for hiding this comment

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

OK. You have introduced a more specific type, but you don't mention it in the docs I've commented above.
Thanks

}
----
====

IMPORTANT: `AnnotationEnhancer` bean definitions cannot be declared in the same class as a `@KafkaListener` method (or class).
It will prevent those listeners from being found by the `KafkaListenerAnnotationBeanPostProcessor`.
Copy link
Member

Choose a reason for hiding this comment

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

Probably better to say that such a bean must be declared static since it is used from the BeanPostProcessor?
Or... The logic in the KafkaListenerAnnotationBeanPostProcessor must be reworked from that InitializingBean.
We probably can collect AnnotationEnhancer beans in the beginning of the afterSingletonsInstantiated() impl...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That is where I had it initially, but it is too late. The beans have all been preprocessed by then. I will look to see if static helps tomorrow.

@artembilan artembilan merged commit ad1ae60 into spring-projects:main Jun 4, 2021
@garyrussell garyrussell deleted the GH-1817 branch June 4, 2021 15:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Allow Users to Post Process @KafkaListener
2 participants