-
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
Resteasy Reactive wants to instantiate abstract ContainerRequestFilter's in dev mode #16359
Labels
Milestone
Comments
quarkus-bot
bot
added
area/devmode
area/rest
env/windows
Impacts Windows machines
labels
Apr 8, 2021
/cc @FroMage, @geoand, @stuartwdouglas |
geoand
added a commit
to geoand/quarkus
that referenced
this issue
Apr 8, 2021
Can you try and give #16360 a shot @Postremus ? |
@geoand The app now starts in dev mode with your PR. Thank you!
|
Awesome, thanks for checking @Postremus |
geoand
added a commit
that referenced
this issue
Apr 8, 2021
Ignore abstract classes in Filter hierarchy
gsmet
pushed a commit
to gsmet/quarkus
that referenced
this issue
Apr 10, 2021
Fixes: quarkusio#16359 (cherry picked from commit ee723bc)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Describe the bug
First of all, I tried to create a reproducer, but was unable to reproduce this issue in an isolated project.
This only happens in dev mode. The app works when starting as fast-jar.
I debugged the problem a bit, and found out that the InstantiationException is thrown because an abstract class was tried to instantied - AbstractAuthenticationFilter.
See the stacktrace, and the screenshot from my debugger below.
This class comes from one of my common modules. It is defined like this:
It is implemented like this:
This works without a problem in Resteasy Classic, but fails in Resteasy Reactive.
Expected behavior
The application should start in dev mode, even when definining abstract ContainerRequestFilter.
Actual behavior
The application does not start in dev mode, and only prints the following log.
To Reproduce
Link to a small reproducer (preferably a Maven project if the issue is not Gradle-specific).
Or attach an archive containing the reproducer to the issue.
Steps to reproduce the behavior:
1.
2.
3.
Configuration
# Add your application.properties here, if applicable.
Screenshots
Environment (please complete the following information):
Output of
uname -a
orver
MSYS_NT-10.0 NANB7NLNVP2 2.10.0(0.325/5/3) 2018-06-13 23:34 x86_64 Msys
Output of
java -version
java version "1.8.0_271"
Java(TM) SE Runtime Environment (build 1.8.0_271-b09)
Java HotSpot(TM) 64-Bit Server VM (build 25.271-b09, mixed mode)
Quarkus version or git rev
1.13.1.Final
Build tool (ie. output of
mvnw --version
orgradlew --version
)Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: C:\eclipse\tools\apache-maven\bin..
Java version: 11.0.7, vendor: Azul Systems, Inc., runtime: C:\eclipse\tools\zulu11.39.15-ca-jdk11.0.7-win_x64
Default locale: de_DE, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
The text was updated successfully, but these errors were encountered: