org.eclipse.jetty.ee9.nested.Request method returning `null`

[ChristianGruen]

Jetty version(s) Jetty 12.1.4

Jetty Environment ee9

Description

Various functions of the org.eclipse.jetty.ee9.nested class, for example getRequestURI(), are allowed to return null. This contrasts with the interface description of the method (https://jakarta.ee/specifications/servlet/5.0/apidocs/jakarta/servlet/http/httpservletrequest#getRequestURI()), and it makes debugging a very erratic process.

My questions:

1. What is the reason for the variant behavior?
2. I cannot find hints to the current design choices in the Java sources. Is the Jetty-specific behavior documented somewhere?
3. Unchecked exceptions would not be ideal either, but they could at least give some more hints on what is going on. Have you thought about that?

[lorban]

Ideally, this should never happen. If that does happen, you're probably navigating somewhere between the unclear parts of the standards and a bug of some sort, not necessarily in Jetty itself.

Throwing an unchecked exception in such case isn't very different from returning null: you reached a sorry place and there is no way for that code to know why nor how.

So you questions raise another one: what are you doing that makes getRequestURI() return null? I suppose this is a question you already asked yourself. The most common cause is when the Request object is used after it has been recycled, i.e.: after the AsyncContext was completed.

This is where I would start investigating.

[ChristianGruen]

So you questions raise another one: what are you doing that makes getRequestURI() return null? I suppose this is a question you already asked yourself. The most common cause is when the Request object is used after it has been recycled, i.e.: after the AsyncContext was completed.

Thanks; this could be a helpful hint. BaseX uses Jetty as a web server. It allows users to start asynchronous server-side jobs in web applications, and the request context is passed to these jobs. In previous versions (up to Jetty 11, maybe later?) it was possible to access the original request information (which was very helpful), but just recently, the behavior seems to have been changed, and I’m trying to find out which information in the (still existing) instance of HttpServletRequest is valid and which isn’t. For example, I noticed that some methods in the Jetty Request class use the comment “not allowed to be null”, but it’s unclear why.