Deprecating MessageHandlingMember annotation specific methods

[smcvb]

This pull request aims to make the MessageHandlingMember interface less focused on annotations. This means the MessageHandlingMember#hasAnnotation(Class<? extends Annotation>) and MessageHandlingMember#annotationAttributes(Class<? extends Annotation>) methods have been deprecated. Obviously replacements are introduced, which come in the form of:

• MessageHandlingMember#isA(String)
• MessageHandlingMember#attributes(String)

This will allow non-annotation focused MessageHandlingMember implementations to provide similar behavior to validate if the member is of a given handler type (the String to provide to the aforementioned methods) and if so to retrieve that handler type's attributes.

Next to this API adjustment, the current AnnotatedMessageHandlingMember should implement these methods too, disregarding the direct usages of annotation classes. To that end, all message handling member annotations are, directly or indirectly, annotated with a new annotation: @HasHandlerAttributes. This allows the framework to based on this meta-annotation find all attributes on each level of an annotation, so that this collection can be used by the AnnotatedMessageHandlingMember to support he new methods.

The find all these attributes, the AnnotationUtils class has been adjusted and appended upon. Adjustment in the form of being able to only retrieve attributes of the target annotation, with potential overridden attributes from higher level annotations which are meta-annotated with the target.

Furthermore a method is included which allows to validate whether a given Annotation Class is meta-annotated with another annotation. This operation is used to check whether an AnnotatedElement like the Executable given to the AnnotatedMessageHandlingMember has annotations which are meta-annotated with HasHandlerAttributes. The two of these AnnotationUtils methods are used to collect all the attributes into a HandlerAttributes object (collected by a HandlerAttributesUtils class). It is this HandlerAttributes which provides the support needed by the AnnotatedMessageHandlingMember to correctly implement the isA(String) and attributes(String) methods.

This pull request should be considered as a form of preparation towards a non-annotation driven MessageHandlingMember.
Note that for any files which have been touched, IDE warnings have been resolved, including some method reordering and JavaDoc uptes.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

90.2% Coverage
0.0% Duplication

Comments processed

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

80.9% Coverage
0.0% Duplication

[rhubarb]

Where does this leave the examples involving using a custom annotation on CommandHandlers and using annotationAttributes to catch them? This doesn't work with the new non-deprecated method because custom annotations are not captured unless they extend Axon annotations

[smcvb]

The MessageHandlingMember#hasAnnotation and MessageHandlingMember#annotationAttributes methods still work as they used to, regardless of this pull request.
They're just marked deprecated in favor of MessageHandlingMember#attributes(String).

For custom annotation, the user is required to meta-annotate they annotation with HasHandlerAttributes.
This could've been deduced from this paragraph in my original description:

Furthermore a method is included which allows to validate whether a given Annotation Class is meta-annotated with another annotation.
This operation is used to check whether an AnnotatedElement like the Executable given to the AnnotatedMessageHandlingMember has annotations which are meta-annotated with HasHandlerAttributes.
The two of these AnnotationUtils methods are used to collect all the attributes into a HandlerAttributes object (collected by a HandlerAttributesUtils class). It is this HandlerAttributes which provides the support needed by the AnnotatedMessageHandlingMember to correctly implement the isA(String) and attributes(String) methods.

However, I could've been clearer that this behavior is the solution for custom annotation too.
Note that I've adjusted the Reference Guide accordingly, following the issue you've constructed, @rhubarb.
Lastly, I'd want to extend my apologies for the uncertainty I've caused by neglecting the Reference Guide changes following this pull request.

I do hope everything is clear right now.
If not, please let us know!