Hello Ethan,
Thank you for noticing this and bringing this up here. I've raised
https://bugs.openjdk.org/browse/JDK-8345577 and we will address this
shortly.
-Jaikiran
On 05/12/24 3:22 am, Ethan McCue wrote:
Sorry
Before:
* {@link Filter} modules may store arbitrary objects with {@code
HttpExchange}
* instances as an out-of-band communication mechanism. Other filters
* or the exchange handler may then access these objects.
Bungled the copy-paste
On Thu, Dec 5, 2024 at 6:49 AM Ethan McCue <et...@mccue.dev> wrote:
Hi all,
This change
(https://github.com/openjdk/jdk/commit/40ae4699622cca72830acd146b7b5c4efd5a43ec)
makes the Jetty implementation of the SPI be no longer fit the
Javadoc.
HttpContexts are not per-request while the previous Javadoc
implied that the attribute mechanism on exchanges was.
Before:
* Sets an attribute with the given {@code name} and {@code
value} in this exchange's
* {@linkplain HttpContext#getAttributes() context attributes}.
* or the exchange handler may then access these objects.
After:
* Sets an attribute with the given {@code name} and {@code
value} in this exchange's
* {@linkplain HttpContext#getAttributes() context attributes}.
*
* @apiNote {@link Filter} modules may store arbitrary objects
as attributes through
* {@code HttpExchange} instances as an out-of-band
communication mechanism. Other filters
* or the exchange handler may then access these objects.
The Jetty implementation, I think rightfully, assumed that this
context was per-request and implemented it as so.
https://github.com/jetty/jetty.project/blob/jetty-12.0.x/jetty-core/jetty-http-spi/src/main/java/org/eclipse/jetty/http/spi/JettyHttpExchangeDelegate.java#L223
As such, I don't think simply a javadoc change as a resolution to
these issues is applicable
https://bugs.openjdk.org/browse/JDK-8345233
https://bugs.openjdk.org/browse/JDK-8235786
