Jersey returns 400 Bad Request, logs nothing: option needed to output exceptions to the browser #5479
Comments
|
which is the exact version of Jersey You've upgraded to? |
|
You cannot use Jersey 3 with Tomcat 9, you need Tomcat 10. See https://tomcat.apache.org/download-10.cgi. |
Jersey v2.39.1, also tried v2.40. Sorry the original description above said jersey3, that was wrong :( |
|
It looks like the point where the bad request originates is here: There is an underlying unmarshalling problem, JAXB is broken, this bubbles up to the above. The exception is then hidden. |
|
Is the exception printed in the Tomcat server log? |
|
Unfortunately tomcat logging is of no use, because you need to know what the exception is to tell tomcat to log it, but without knowing what the exception is, you can't tell tomcat what to log. I eventually stopped it in a debugger by breakpointing on all exceptions. For some reason jersey was trying to use an Oracle SAX parser that wasn't being pulled in transitively. Providing the missing jar above also didn't work, I don't remember why, I've been going round in circles and I've forgotten what I tried. I tried to upgrade all of JAXB to jakarta.xml across the board, but it appears that jersey v2.41 doesn't support the jakarta version of JAXB. Does a matrix exist anywhere of what versions of jersey is compatible with what? I am aware that breaking changes were made in the v2.x series, and I cannot for the life of me find a combination of jars (jersey, jaxb, persistence) that works. I am stuck on tomcat9, that cannot change. I understand that means I am stuck on jersey v2.41, that cannot change. What is compatible with jersey v2.41? |
|
Jersey 2.x works with javax namespace, so whatever jakarta jar contains javax namespace (such as jaxb 2.3.2), Jersey supports it. |
|
What is confusing me horribly is that the POM of jersey-media-jaxb will tell me it depends on jakarta.xml.bind-api, but exceptions thrown by jersey are telling me that javax.xml APIs are missing. I am now getting jersey telling me that application/xml is 415 – Unsupported Media Type in code that receives XML. |
|
Yes, it is confusing. |
Can you confirm the exact maven coordinates of jaxb 2.3.2 if possible? this version doesn't appear to exist (v2.3.1 exists). |
Are there any maven coordinates for jakarta prefixed jars with javax packages inside? The inconsistent naming makes this impossible to search for. |
|
This is the maven coordinates I am using right now: |
|
I would recommend using what Jersey is tested with. Some dependencies (non-Jakarta) break backward compatibility without upgrading its major version. |
|
Interestingly, you have both versions of JAX-B, but you are missing the implementation, I'd recommend |
|
Managed to massage things until the dependencies look like this, and I am back to the original 400 Bad Request right at the top. It looks like we're missing an XML parser, but something buried in here is hard coded to look for something from Oracle. |
|
Chasing two bugs here. The first is whatever in Jersey is triggering the 400 Bad Request, which may be the ClassNotFoundException, but may not be, as other ClassNotFoundExceptions are thrown making reference to classes in tomcat itself. The second bug is a Tomcat bug, or it might be a Tomcat bug triggered by a Jersey bug, where we arrive at the following code that handles the printout of the 400 error, and there is no throwable (it is null): No throwable, and an unhandled 400 Bad Request, and we get Tomcat's generic error screen with no exception and nothing logged. |
|
Found the source of the Oracle XML parser: For some reason jersey has hard coded the name of an Oracle implementation of the class Trying to use this implementation breaks Datanucleus, which only works with Xerces. Does jersey2 work on JDKs above java8 with all the XML code removed? |
|
This is interesting, but it only logs information that the class was not found under FINER level logging. That does not break the runtime. You would likely see 500 if an exception would be thrown. Under the FINER logging level, you should see the message "Starting mapping of the exception." in the server log, followed by the exception. But 400 is often a Tomcat Exception (caused by incorrect libraries in Tomcat), thrown before Jersey has an opportunity to do anything. |
|
I am also experiencing same kind of problem with Jersey 3 with Tomcat 10.1.18 . Whats happening for me is when requests with empty path parameters are passed 400 bad request is thrown without any logging. But for request like this are passing normally The main thing is request is not reaching the spring layer. The request is passed from Tomcat without any changes in the path. Only logging I can see is request access log from Tomcat which just shows the request path and error code. |
|
@minfrin I am checking this: https://github.com/gluser1357/jerseyissues/tree/issue-5404-crosscontext It is working in latest 3.1 (I am testing with the compiled Jersey 3.1 branch that has the version 3.1.99-SNAPSHOT) |
|
This is what I am using in my project This is the latest available jersey version in maven repository. This is my configuration in web.xml And this is what I am getting in Tomcat localhost access log
The error I'm getting in Postman is Other than these, I dont have any trace or reason for this behaviour. Could you please try testing with // [Consecutive slashes] |
|
I am getting 404 in Jersey instead of 400, in this stacktrace: With this resource method: @Gokul-2720 Could you share a simple app that throws 400?. I am not able to reproduce your issue. |
|
I dont know what is happening here, If I provide values for all the path parameters like you did, I get 200 response code and API is returning the response properly. http://localhost:9090/proactive-api/rest/api/deviceManagement/gokul/PHONE/a/b/100/c/d/0/gokul Tomcat access log: But when the path parameters are empty I'm getting 400 bad request. Actually I'm working on a complex enterprise application upgrade. Let me check whether I can provide any simple application with you. |
On an existing long standing application, after an upgrade to tomcat9 and jersey3, attempts to hit the application cause tomcat to return the following response:
Jersey needs a property that can be passed to the JDK that causes Jersey to output full stacktraces out of the front door for forensic debugging.
Server side logging is impossible to configure without already knowing what the problem is.
The text was updated successfully, but these errors were encountered: