[UNDERTOW-2157 / 2103 / 2644 / 2231 / 2269] Backport fixes to 2.3.x#1830
Merged
Conversation
…y contract, fix bug BufferedWriteableOutputStream is currently implemented by: 1. UndertowOutputStream 2. ServletOutputStreamImpl These have two different behaviours. In UndertowOutputStream, I _believe_ that if the input FileChannel's position is 0, it transfers the whole channel, and if it's non-zero, it crashes. In ServletOutputStreamImpl, I think the behaviour is something more like: 1. If there is no listener set, transfer the bytes between the current position and end of file. 2. If there is a listener set, transfer the bytes between the current position and end of file, setting the input channel's position as well. This PR makes the behaviour be more consistent and adds a new, clearer API, deprecating the old one. 1. Clarify the contract of BufferedWriteableOutputStream.transferTo as being the ServletOutputStreamImpl's behaviour, since it has a superset of the UndertowOutputStream's functionality. 2. Never set the position of the input channel in ServletOutputStreamImpl, since it leads to inconsistent behaviour depending on whether the listener is set and seems incongruent with the contract of the underlying FileChannel apis. 3. Add an explicit `transferFrom(FileChannel source, long startPosition, long count)` method to the interface and implement in both implementations. In theory there is a breaking behaviour change for the user who is relying on their FileChannel's position being set to EOF as a side-effect of the change. Internally to Undertow there is no problem here.
Signed-off-by: Flavia Rainone <frainone@redhat.com>
…oved Signed-off-by: Flavia Rainone <frainone@redhat.com>
Signed-off-by: Flavia Rainone <frainone@redhat.com>
…ts, also improve the job naming Signed-off-by: Flavia Rainone <frainone@redhat.com>
Signed-off-by: Flavia Rainone <frainone@redhat.com>
Signed-off-by: Flavia Rainone <frainone@redhat.com>
fl4via
added
waiting CI check
This was referenced Oct 27, 2025
Merged
Merged
…rge of parameters Signed-off-by: Flavia Rainone <frainone@redhat.com>
fl4via
force-pushed
the
backport-fixes_2.3.x
branch
from
b26d3d9 to
78f4223
Compare
Contributor
|
Last nights TCK run reported a JSP/Jakarta Pages TCK failure after this change and other changes were merged to WildFly. We see a failure in the |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Jiras:
https://issues.redhat.com/browse/UNDERTOW-2157 Main PR: #1372
https://issues.redhat.com/browse/UNDERTOW-2103 Main PR: #1328
https://issues.redhat.com/browse/UNDERTOW-2644 Main PR: #1328
https://issues.redhat.com/browse/UNDERTOW-2231 Main PR: #1460
https://issues.redhat.com/browse/UNDERTOW-2269 Main PR: #1478
2.2.x PR: #1829
2.4.x PR: #1831