Take class hierarchy into account when resolving #290
Conversation
Qodana Community for JVMIt seems all right 👌 No new problems were found according to the checks applied 💡 Qodana analysis was run in the pull request mode: only the changed files were checked View the detailed Qodana reportTo be able to view the detailed Qodana report, you can either:
To get - name: 'Qodana Scan'
uses: JetBrains/qodana-action@v2023.2.8
with:
upload-result: trueContact Qodana teamContact us at qodana-support@jetbrains.com
|
| */ | ||
| class CommonHandlerMethodLineMarkerProvider : AbstractHandlerLineMarkerProvider() { | ||
| private val blacklistedTypes = listOf(MessageHandlerType.DEADLINE, MessageHandlerType.COMMAND, MessageHandlerType.COMMAND_INTERCEPTOR) | ||
| private val blacklistedTypes = listOf(MessageHandlerType.DEADLINE) |
There was a problem hiding this comment.
Not sure that I comprehend why only the DEADLINE is left for black listing. Care to explain?
There was a problem hiding this comment.
This class marks any @MessageHander annotated method, unless that handler type is in the list.
Before this PR, a command handler had a specific one, but with the interceptors gone it's not needed. Aditionally, in the future, the interceptors will be generic for any type of message and implemented in this provider.
The reason deadline is still here is because this is a specific one (DeadlineHandlerMethodLineMarkerProvider) because it uses the DeadlineManagerReferenceResolver instead of the MessageHandlerResolver
There was a problem hiding this comment.
I left it a list, because maybe we need different MarkerProviders later after all
There was a problem hiding this comment.
Thanks for the explanation; it makes sense to me!
Both when resolving handlers and creators, the hierarchy of classes was not interpreted correctly. This has been resolved. In addition, I discovered that the current interceptor implementation stood in the way of this fix, and that it should be implemented in another way. Interceptors are not handlers, after all, but this mechanism was abused for that. As such, the CommandHandlerInterceptor support has been removed. This may be re-added in the future.
# Conflicts: # CHANGELOG.md # src/main/kotlin/org/axonframework/intellij/ide/plugin/resolving/handlers/searchers/CommandHandlerInterceptorSearcher.kt # src/main/kotlin/org/axonframework/intellij/ide/plugin/resolving/handlers/types/CommandHandlerInterceptor.kt
CodeDrivenMitch
force-pushed
the
fix/take-hierarchy-into-account
branch
from
41ef75f to
0425dbc
Compare
Both when resolving handlers and creators, the hierarchy of classes was not interpreted correctly. This has been resolved.
In addition, I discovered that the current interceptor implementation stood in the way of this fix, and that it should be implemented in another way. Interceptors are not handlers, after all, but this mechanism was abused for that. As such, the CommandHandlerInterceptor support has been removed. This may be re-added in the future.