-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Hibernate reactive panache - validation of interceptor bindings #31846
Hibernate reactive panache - validation of interceptor bindings #31846
Conversation
mkouba
commented
Mar 14, 2023
- the build only fails if any of [WithSession, WithTransaction, WithSessionOnDemand] is declared on a method that does not return Uni
- if declared on a class then the methods that do not return Uni are effectively ignored
- the build only fails if any of [WithSession, WithTransaction, WithSessionOnDemand] is declared on a method that does not return Uni - if declared on a class then the methods that do not return Uni are effectively ignored
I believe that the new behavior makes more sense and is more practical in overall. |
This comment has been minimized.
This comment has been minimized.
* A method annotated with this annotation must return either {@link io.smallrye.mutiny.Uni}. If declared on a class then all | ||
* methods that are intercepted must return {@link io.smallrye.mutiny.Uni}. | ||
* A method annotated with this annotation must return {@link io.smallrye.mutiny.Uni}. If declared on a class then all methods | ||
* that return {@link io.smallrye.mutiny.Uni} are considered; all other methods are ignored. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we really want this? I guess it's an inconvenience to have to annotate multiple methods if necessary, but isn't it better than having a method ignored because the user forgot that it must return a Uni?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, it depends. I agree that the current behavior is a bit more correct.
But sometimes you need transaction/session for 80% of the methods but not for few package-private or protected methods, usually some utils inherited from a superclass. And in this case it's very inconvenient to annotate each method.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To me is the difference between adding a couple of annotations and having to debug an issue that's hard to spot.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Anyway, I don't have a strong opinion, we could also add a property in the annotation to enable/disable strict validation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That seems useful to me. +1
Failing Jobs - Building 2239362
Full information is available in the Build summary check run. Failures⚙️ Gradle Tests - JDK 11 Windows #📦 integration-tests/gradle✖
✖
✖
|