<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"></div><div dir="ltr">Hi,</div><div dir="ltr"><br></div><div dir="ltr">I read the bug report. I don’t think this is sufficient. This is a specification so in order to have compliant behavior no matter the implementation there cannot be a different set of rules for the reference implementation vs others. </div><div dir="ltr"><br></div><div dir="ltr">So the api should be clarified in a non ambiguous manner and then one or more implementations can be classified as non compliant. </div><div dir="ltr"><br></div><div dir="ltr">Robert</div><div dir="ltr"><br><blockquote type="cite">On Dec 5, 2024, at 6:31 AM, Jaikiran Pai <jai.forums2013@gmail.com> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr">

  
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  
  
    <p>Hello Ethan,</p>
    <p>Thank you for noticing this and bringing this up here. I've
      raised <a class="moz-txt-link-freetext" href="https://bugs.openjdk.org/browse/JDK-8345577">https://bugs.openjdk.org/browse/JDK-8345577</a> and we will
      address this shortly.</p>
    <p>-Jaikiran<br>
    </p>
    <div class="moz-cite-prefix">On 05/12/24 3:22 am, Ethan McCue wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:CA+NR86j_tJ9FkAJP97oLum8iWmBDroadgxc1JK9DSj9y4Ue1Bg@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">Sorry<br>
        <br>
        Before:<br>
        <br>
        <font face="monospace">     * {@link Filter} modules may store
          arbitrary objects with {@code HttpExchange}</font><br>
        <font face="monospace">     * instances as an out-of-band
          communication mechanism. Other filters</font><br>
        <font face="monospace">     * or the exchange handler may then
          access these objects.</font><br>
        <br>
        <font face="arial, sans-serif">Bungled the copy-paste</font></div>
      <br>
      <div class="gmail_quote gmail_quote_container">
        <div dir="ltr" class="gmail_attr">On Thu, Dec 5, 2024 at 6:49 AM
          Ethan McCue <<a href="mailto:ethan@mccue.dev" moz-do-not-send="true" class="moz-txt-link-freetext">ethan@mccue.dev</a>>
          wrote:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
          <div dir="ltr">Hi all,<br>
            <br>
            This change (<a href="https://github.com/openjdk/jdk/commit/40ae4699622cca72830acd146b7b5c4efd5a43ec" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/openjdk/jdk/commit/40ae4699622cca72830acd146b7b5c4efd5a43ec</a>)
            makes the Jetty implementation of the SPI be no longer fit
            the Javadoc.<br>
            <br>
            HttpContexts are not per-request while the previous Javadoc
            implied that the attribute mechanism on exchanges was.<br>
            <br>
            Before:<br>
            <br>
            <font face="monospace">     * Sets an attribute with the
              given {@code name} and {@code value} in this exchange's<br>
                   * {@linkplain HttpContext#getAttributes() context
              attributes}.<br>
                   * or the exchange handler may then access these
              objects.</font><br>
            <br>
            After:<br>
            <br>
            <font face="monospace">     * Sets an attribute with the
              given {@code name} and {@code value} in this exchange's<br>
                   * {@linkplain HttpContext#getAttributes() context
              attributes}.<br>
                   *<br>
                   * @apiNote {@link Filter} modules may store arbitrary
              objects as attributes through<br>
                   * {@code HttpExchange} instances as an out-of-band
              communication mechanism. Other filters<br>
                   * or the exchange handler may then access these
              objects.<br>
            </font><br>
            The Jetty implementation, I think rightfully, assumed that
            this context was per-request and implemented it as so.<br>
            <br>
            <a href="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" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">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</a><br>
            <br>
            As such, I don't think simply a javadoc change as a
            resolution to these issues is applicable<br>
            <br>
            <a href="https://bugs.openjdk.org/browse/JDK-8345233" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://bugs.openjdk.org/browse/JDK-8345233</a><br>
            <a href="https://bugs.openjdk.org/browse/JDK-8235786" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://bugs.openjdk.org/browse/JDK-8235786</a><br>
            <br>
          </div>
        </blockquote>
      </div>
    </blockquote>
  

</div></blockquote></body></html>