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
Implement Eclipse Jetty core HTTP handler adapter #32097
base: main
Are you sure you want to change the base?
Conversation
@gregw Please sign the Contributor License Agreement! Click here to manually synchronize the status of this Pull Request. See the FAQ for frequently asked questions. |
@pivotal-cla Working on getting a CCLA signed. Stand by.... |
|
||
@Override | ||
public <T> T getNativeRequest() { | ||
return null; |
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.
@lachlan-roberts this could be the ServerRequest passed into the builder?
@lachlan-roberts can you sign the individual CLA. |
This PR is failing 2 tests that undertow also fails: See #25310. |
@gregw Thank you for signing the Contributor License Agreement! |
// TODO: Why does intellij warn about possible blocking call? | ||
// Because it can block and we want to be fully asynchronous. Use AsynchronousFileChannel | ||
SeekableByteChannel channel = Files.newByteChannel(file, StandardOpenOption.READ); |
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.
Files.newByteChannel
is a blocking operation, but I see that undertow also use it and just live with the warning. The chance of it actually blocking for any significant time is vanishingly small and there is no chance of dead lock.
// this.dataBuffer = dataBufferFactory.wrap(BufferUtil.copy(chunk.getByteBuffer())); // TODO this copy avoids multipart bugs | ||
this.dataBuffer = dataBufferFactory.wrap(chunk.getByteBuffer()); // TODO avoid double slice? |
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.
This is the work around for the failing multipart tests (see #25310)
...g-web/src/main/java/org/springframework/http/server/reactive/JettyCoreServerHttpRequest.java
Outdated
Show resolved
Hide resolved
...g-web/src/main/java/org/springframework/http/server/reactive/JettyCoreServerHttpRequest.java
Outdated
Show resolved
Hide resolved
...g-web/src/main/java/org/springframework/http/server/reactive/JettyCoreServerHttpRequest.java
Outdated
Show resolved
Hide resolved
…pResponse Signed-off-by: Lachlan Roberts <lachlan@webtide.com>
…HttpResponse Signed-off-by: Lachlan Roberts <lachlan@webtide.com>
Signed-off-by: Lachlan Roberts <lachlan@webtide.com>
Signed-off-by: Lachlan Roberts <lachlan@webtide.com>
Signed-off-by: Lachlan Roberts <lachlan@webtide.com>
Signed-off-by: Lachlan Roberts <lachlan@webtide.com>
Signed-off-by: Lachlan Roberts <lachlan.p.roberts@gmail.com>
Signed-off-by: Lachlan Roberts <lachlan.p.roberts@gmail.com>
Signed-off-by: Lachlan Roberts <lachlan.p.roberts@gmail.com>
Signed-off-by: Lachlan Roberts <lachlan.p.roberts@gmail.com>
@jhoeller Is there anything process wise that we need to do to move this PR on? It would be good to get some review to make sure we are on the right path. |
Signed-off-by: Lachlan Roberts <lachlan.p.roberts@gmail.com>
Signed-off-by: Lachlan Roberts <lachlan.p.roberts@gmail.com>
Update spring Jetty websocket usage
@gregw Hi Greg, sorry for the recent lack of feedback. I plan to take a look at this PR soon, and hopefully we can merge it in 6.2 M2 or M3. |
This provides an implementation of a HTTP Handler Adaptor that is coded directly to the Eclipse Jetty core API, bypassing any servlet implementation.
Fixes #32035