-
Notifications
You must be signed in to change notification settings - Fork 562
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
MP apps receiving OPTIONS request triggers failure in Jersey #1684
Comments
Santiago and I chatted with Jan about this. He is looking into whether Jersey could defer trying to locate the JAX-B implementation even later, so in our use case it would not be needed at all. That would resolve the original use case, in which our CORS handling, not Jersey's WADL endpoint, responds to the But separately/in the meantime we need to decide what we want to do about general MP apps. Currently any Jan mentioned that setting We might need a way for users to override Helidon's disabling of that feature if they wanted the out-of-the-box Jersey behavior. At least that way, if they turned this on, they'd have taken an explicit action and could reasonably be held responsible for also making sure a JAX-B implementation is available. |
Jan suggested that Helidon could do the same attempted class look-up that the Jersey WADL code does. If Helidon does not find the class then it could set the server property mentioned above. That avoids the need for an explicit way for users to override any change inside Helidon: If the user puts a JAX-B implementation on the class path then Helidon will let Jersey use it. |
It looks as if the trouble starts if the client sends the |
Jan has a Jersey PR to fix this: eclipse-ee4j/jersey#4450 If a new Jersey release will be out soon we might as well adopt it and avoid making any changes to Helidon code. |
Jan reports that Jersey is anticipating releasing 2.31 (which will contain this fix) around May 8-11. |
See also #1887 |
With #1887 merged, I rebuilt the MP Quickstart example. Gratifyingly, server start-up logs this new message:
and sending the same
|
Environment Details
Under certain circumstances, Jersey needs to load JAX-B classes at runtime. For example, neither the generated quickstart pom nor the MP bundle it depends on includes dependencies to satisfy the look-up so Jersey complains and the HTTP request fails.
Inspired by the reproducer described in #1562, here is a simpler one:
curl
command or its equivalent:and the quickstart app creates a long stack trace. (See below.)
Adding both of these dependencies to the quickstart pom:
resolves the problem and your client shows XML WADL output describing the endpoint, which explains why Jersey was looking for the JAX-B classes.
This problem is not unique to the MP quickstart app. Any MP app could have the same problem when sent an
OPTIONS
request.The text was updated successfully, but these errors were encountered: