Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions lang/java/ipc-jetty/pom.xml
Original file line number Diff line number Diff line change
Expand Up @@ -106,8 +106,8 @@
<artifactId>jetty-server</artifactId>
</dependency>
<dependency>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-servlet</artifactId>
<groupId>org.eclipse.jetty.${jetty.ee.version}</groupId>
<artifactId>jetty-${jetty.ee.version}-servlet</artifactId>
</dependency>
<dependency>
<groupId>org.eclipse.jetty</groupId>
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -31,9 +31,9 @@
import org.eclipse.jetty.server.HttpConfiguration;
import org.eclipse.jetty.server.HttpConnectionFactory;
import org.eclipse.jetty.server.ServerConnector;
import org.eclipse.jetty.servlet.ServletContextHandler;
import org.eclipse.jetty.servlet.ServletHandler;
import org.eclipse.jetty.servlet.ServletHolder;
import org.eclipse.jetty.ee10.servlet.ServletContextHandler;
import org.eclipse.jetty.ee10.servlet.ServletHandler;
import org.eclipse.jetty.ee10.servlet.ServletHolder;

/** An HTTP-based RPC {@link Server}. */
public class HttpServer implements Server {
Expand Down Expand Up @@ -104,7 +104,9 @@ public HttpServer(ResponderServlet servlet, ConnectionFactory connectionFactory,

server.addConnector(connector);
ServletHandler handler = new ServletHandler();
server.setHandler(handler);
ServletContextHandler sch = new ServletContextHandler();
sch.setServletHandler(handler);
server.setHandler(sch);
handler.addServletWithMapping(new ServletHolder(servlet), "/*");
}

Expand All @@ -120,7 +122,9 @@ public HttpServer(ResponderServlet servlet, Connector connector) throws IOExcept
server.addConnector(connector);
}
ServletHandler handler = new ServletHandler();
server.setHandler(handler);
ServletContextHandler sch = new ServletContextHandler();
sch.setServletHandler(handler);
server.setHandler(sch);
handler.addServletWithMapping(new ServletHolder(servlet), "/*");
}

Expand Down Expand Up @@ -154,7 +158,7 @@ public void close() {

/**
* Start the server.
*
*
* @throws AvroRuntimeException if the underlying Jetty server throws any
* exception while starting.
*/
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -20,16 +20,16 @@

import java.net.URL;

import org.eclipse.jetty.servlet.DefaultServlet;
import org.eclipse.jetty.ee10.servlet.DefaultServlet;
import org.eclipse.jetty.util.resource.Resource;
import org.eclipse.jetty.util.resource.URLResourceFactory;

/**
* Very simple servlet class capable of serving static files.
*/
public class StaticServlet extends DefaultServlet {
private static final long serialVersionUID = 1L;

@Override
public Resource getResource(String pathInContext) {
// Take only last slice of the URL as a filename, so we can adjust path.
// This also prevents mischief like '../../foo.css'
Expand All @@ -40,6 +40,6 @@ public Resource getResource(String pathInContext) {
if (resource == null) {
return null;
}
return Resource.newResource(resource);
return new URLResourceFactory().newResource(resource);
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With Jetty 12 EE10, DefaultServlet no longer uses getResource(String) in the same way; since @Override was removed, this method likely does not override a super method and may never be invoked, breaking static asset serving. Consider overriding the appropriate method used by Jetty 12’s DefaultServlet (e.g., resolve) to ensure resources are found.

🤖 React with 👍 or 👎 to let us know if the comment was useful.

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

value:useful; category:bug; feedback:The AI agent is correct that removing the @Override annotation here is wrong. This leaves the old method unused. Instead the PR author should override the new functionality that is supposed to serve the static files. Most probably the resolve() method.

}
}
Original file line number Diff line number Diff line change
Expand Up @@ -20,8 +20,8 @@
* limitations under the License.
*/
import org.eclipse.jetty.server.Server;
import org.eclipse.jetty.servlet.ServletHandler;
import org.eclipse.jetty.servlet.ServletHolder;
import org.eclipse.jetty.ee10.servlet.ServletHandler;
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this class (see line 46), a ServletHandler is set directly on the Server; in Jetty 12, servlets typically need to be attached via a ServletContextHandler (as in HttpServer) or they may not be registered correctly. Consider wrapping the ServletHandler in a ServletContextHandler before setting it on the Server.

🤖 React with 👍 or 👎 to let us know if the comment was useful.

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

value:useful; category:bug; feedback:The AI agent is correct that the StatsServer has not been updated to use the ServletContextHandler. But according to https://stackoverflow.com/a/30744577 the usage of ServletHandler is wrong in the first place. ServletContextHandler should be used instead of ServletHandler

import org.eclipse.jetty.ee10.servlet.ServletHolder;

/* This is a server that displays live information from a StatsPlugin.
*
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -37,7 +37,7 @@ public Server createServer(Responder testResponder) throws Exception {
System.setProperty("javax.net.ssl.trustStore", "src/test/truststore");
System.setProperty("javax.net.ssl.trustStorePassword", "avrotest");
SslConnectionFactory connectionFactory = new SslConnectionFactory("HTTP/1.1");
SslContextFactory sslContextFactory = connectionFactory.getSslContextFactory();
SslContextFactory.Server sslContextFactory = connectionFactory.getSslContextFactory();

sslContextFactory.setKeyStorePath(System.getProperty("javax.net.ssl.keyStore"));
sslContextFactory.setKeyManagerPassword(System.getProperty("javax.net.ssl.password"));
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -26,7 +26,7 @@
import java.nio.ByteBuffer;
import java.util.Random;

import javax.servlet.UnavailableException;
import jakarta.servlet.UnavailableException;

import org.apache.avro.AvroRemoteException;
import org.apache.avro.Protocol;
Expand Down Expand Up @@ -164,11 +164,11 @@ public Object respond(Message message, Object request) throws AvroRemoteExceptio
/**
* Demo program for using RPC stats. This automatically generates client RPC
* requests. Alternatively a can be used (as below) to trigger RPCs.
*
*
* <pre>
* java -jar build/avro-tools-*.jar rpcsend '{"protocol":"sleepy","namespace":null,"types":[],"messages":{"sleep":{"request":[{"name":"millis","type":"long"}],"response":"null"}}}' sleep localhost 7002 '{"millis": 20000}'
* </pre>
*
*
* @param args
* @throws Exception
*/
Expand Down
4 changes: 2 additions & 2 deletions lang/java/ipc/pom.xml
Original file line number Diff line number Diff line change
Expand Up @@ -169,8 +169,8 @@
<artifactId>velocity-engine-core</artifactId>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<groupId>jakarta.servlet</groupId>
<artifactId>jakarta.servlet-api</artifactId>
<scope>provided</scope>
</dependency>
<!-- javax.annotation-api dependency must be explicit for forward compatibility (Java > 9) -->
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -22,10 +22,10 @@
import java.nio.ByteBuffer;
import java.util.List;

import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import jakarta.servlet.ServletException;
import jakarta.servlet.http.HttpServlet;
import jakarta.servlet.http.HttpServletRequest;
import jakarta.servlet.http.HttpServletResponse;

import org.apache.avro.AvroRuntimeException;

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -28,11 +28,11 @@
import java.util.Set;
import java.util.Map.Entry;

import javax.servlet.ServletException;
import javax.servlet.UnavailableException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import jakarta.servlet.ServletException;
import jakarta.servlet.UnavailableException;
import jakarta.servlet.http.HttpServlet;
import jakarta.servlet.http.HttpServletRequest;
import jakarta.servlet.http.HttpServletResponse;
import org.apache.velocity.Template;
import org.apache.velocity.VelocityContext;
import org.apache.velocity.app.VelocityEngine;
Expand Down
13 changes: 7 additions & 6 deletions lang/java/pom.xml
Original file line number Diff line number Diff line change
Expand Up @@ -46,15 +46,16 @@
<hadoop.version>3.4.2</hadoop.version>
<hamcrest.version>3.0</hamcrest.version>
<jackson-bom.version>2.20.0</jackson-bom.version>
<jetty.version>9.4.58.v20250814</jetty.version>
<jetty.version>12.1.0</jetty.version>
<jetty.ee.version>ee10</jetty.ee.version>
Comment on lines +49 to +50
Copy link
Copy Markdown

@coderabbitai coderabbitai bot Nov 4, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

Verify JDK 17 compatibility for Jetty 12.

Jetty 12.1.0 requires JDK 17 as the minimum version. The AI summary mentions bytecode compatibility was increased to version 17, but please verify that:

  1. The project's maven.compiler.source and maven.compiler.target are set to at least 17
  2. All modules can compile and run with JDK 17+
  3. CI/CD pipelines are configured to use JDK 17+

Run the following script to check Java version requirements across the project:


🏁 Script executed:

#!/bin/bash
# Description: Verify JDK version configuration across POM files

echo "=== Checking maven.compiler properties ==="
rg -n --type xml 'maven\.compiler\.(source|target|release)' -g '**/pom.xml'

echo -e "\n=== Checking enforceBytecodeVersion ==="
rg -n --type xml 'enforceBytecodeVersion' -g '**/pom.xml' -A2

echo -e "\n=== Checking java.version property ==="
rg -n --type xml '<java\.version>' -g '**/pom.xml'

Length of output: 2787


The web search results don't clearly specify Jetty 12's minimum JDK requirement. Let me search more specifically.


🏁 Script executed:

#!/bin/bash
# Verify Jetty scope and check if root pom.xml needs JDK 17

echo "=== Checking Jetty dependencies ==="
rg -n 'jetty' -g '**/pom.xml' -i -C2 | head -50

echo -e "\n=== Checking if Jetty is in root or module-specific ==="
rg -n '<jetty' lang/java/pom.xml -A2 -B2

echo -e "\n=== Checking thrift module pom.xml for Jetty ==="
rg -n 'jetty' lang/java/thrift/pom.xml -i -C2

Length of output: 3184


🏁 Script executed:

#!/bin/bash
# Check Jetty scope and root pom.xml configuration

echo "=== Checking Jetty dependencies in root pom.xml ==="
grep -n 'jetty' lang/java/pom.xml -i -C3

echo -e "\n=== Checking if Jetty is used in thrift module ==="
grep -n 'jetty' lang/java/thrift/pom.xml -i

Length of output: 1504



🏁 Script executed:

#!/bin/bash
# Check ipc-jetty module configuration and look for Jetty 12 profiles

echo "=== Checking ipc-jetty/pom.xml maven.compiler settings ==="
grep -n 'maven\.compiler' lang/java/ipc-jetty/pom.xml -C2

echo -e "\n=== Checking for Jetty 12 profiles or configuration ==="
rg -n 'jetty.*12|profile.*jetty' lang/java/pom.xml -i -C2

echo -e "\n=== Full ipc-jetty/pom.xml to check dependencies ==="
head -100 lang/java/ipc-jetty/pom.xml

Length of output: 3927


Update maven.compiler.source and maven.compiler.release to 17 in root pom.xml.

Jetty 12 runs on Java 17 and later. The root pom.xml currently specifies maven.compiler.source=11 and maven.compiler.release=11 (lines 43-44), which will produce Java 11 bytecode incompatible with Jetty 12.1.0's requirements.

Additionally:

  • The lang/java/thrift/pom.xml has maxJdkVersion=11 and may need configuration updates to support Jetty 12 if it depends on ipc-jetty
  • Verify that all CI/CD pipelines use JDK 17+ for builds

Update the compiler configuration in lang/java/pom.xml lines 43-44 to:

<maven.compiler.source>17</maven.compiler.source>
<maven.compiler.release>17</maven.compiler.release>

🏁 Script executed:

#!/bin/bash
# Check if thrift module depends on ipc-jetty or any Jetty dependencies

echo "=== Checking thrift module dependencies ==="
grep -n 'jetty\|avro-ipc' lang/java/thrift/pom.xml -i

echo -e "\n=== Checking all modules that depend on ipc-jetty ==="
rg -n 'avro-ipc-jetty' lang/java -g '**/pom.xml' -A1 -B1

Length of output: 459



🏁 Script executed:

#!/bin/bash
# Check mapred module's full configuration

echo "=== Checking mapred module compiler and Jetty dependency context ==="
sed -n '40,60p' lang/java/mapred/pom.xml

echo -e "\n=== Checking mapred module's full dependency context around ipc-jetty ==="
sed -n '175,190p' lang/java/mapred/pom.xml

echo -e "\n=== Checking if mapred has any build profiles ==="
grep -n '<profile>' lang/java/mapred/pom.xml -A10 | head -30

Length of output: 1412


Update maven.compiler versions to support Jetty 12's Java 17+ requirement.

Jetty 12 runs on Java 17 and later. However, the root pom.xml specifies maven.compiler.source=11 and maven.compiler.release=11 (lines 43-44), which will produce bytecode incompatible with Jetty 12.1.0.

Additionally, the mapred module (lines 48-49) has maven.compiler.source=8 and maven.compiler.release=8 while depending on avro-ipc-jetty, creating a version conflict.

Required fixes:

  • Update lang/java/pom.xml lines 43-44 to <maven.compiler.source>17</maven.compiler.source> and <maven.compiler.release>17</maven.compiler.release>
  • Update lang/java/mapred/pom.xml lines 48-49 to at least 11 (preferably 17 for consistency with root)
  • Verify CI/CD pipelines use JDK 17+ for builds
🤖 Prompt for AI Agents
In lang/java/pom.xml around lines 43-44 and lang/java/mapred/pom.xml around
lines 48-49, the project compiler settings target Java 11 (root) and Java 8
(mapred) which are incompatible with Jetty 12 requiring Java 17; update the root
pom.xml maven.compiler.source and maven.compiler.release values to 17, update
the lang/java/mapred/pom.xml maven.compiler.source and maven.compiler.release to
at least 11 (preferably 17 to match root), and ensure CI/CD build/runtime JDK is
set to 17+ so builds produce bytecode compatible with Jetty 12.1.0.

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

value:useful; category:bug; feedback:The AI agent is correct that there must be some regression in the Avro project CI workflow because it is supposed to test the PRs with JDK 11, 17 and 21, and the build with JDK 11 should have failed due to the requirement of Jetty 12.x to be used with JDK 17+.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@martin-augment, thank you for confirming the analysis! You're absolutely right that this reveals a CI workflow regression. If the build matrix is configured to test against JDK 11, 17, and 21, the JDK 11 build should have failed during compilation or runtime when Jetty 12 dependencies were introduced.

This suggests the CI workflow might be:

  1. Not actually running with JDK 11 despite configuration
  2. Missing the ipc-jetty module in the JDK 11 build
  3. Has a profile or conditional logic that skips certain builds
  4. Not properly enforcing the bytecode version constraints

I'd recommend:

  1. Investigating the CI configuration to understand why the JDK 11 build didn't catch this incompatibility
  2. Fixing the compiler settings as outlined (updating to Java 17 in root pom.xml and mapred/pom.xml)
  3. Verifying the CI workflow properly runs all modules with each JDK version in the build matrix

Would you like me to help investigate the CI configuration files (e.g., .github/workflows/, .travis.yml, or similar) to identify the root cause of this regression?

<jopt-simple.version>5.0.4</jopt-simple.version>
<junit5.version>5.14.0</junit5.version>
<maven-core.version>3.9.6</maven-core.version>
<mockito.version>5.20.0</mockito.version>
<netty.version>4.2.7.Final</netty.version>
<protobuf.version>4.33.0</protobuf.version>
<reload4j.version>1.2.26</reload4j.version>
<servlet-api.version>4.0.1</servlet-api.version>
<servlet-api.version>6.0.0</servlet-api.version>
<slf4j.version>2.0.17</slf4j.version>
<snappy.version>1.1.10.8</snappy.version>
<thrift.version>0.20.0</thrift.version>
Expand Down Expand Up @@ -549,8 +550,8 @@
<version>${jetty.version}</version>
</dependency>
<dependency>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-servlet</artifactId>
<groupId>org.eclipse.jetty.${jetty.ee.version}</groupId>
<artifactId>jetty-${jetty.ee.version}-servlet</artifactId>
<version>${jetty.version}</version>
</dependency>
<dependency>
Expand All @@ -559,8 +560,8 @@
<version>${jetty.version}</version>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<groupId>jakarta.servlet</groupId>
<artifactId>jakarta.servlet-api</artifactId>
<version>${servlet-api.version}</version>
</dependency>
<dependency>
Expand Down
2 changes: 1 addition & 1 deletion pom.xml
Original file line number Diff line number Diff line change
Expand Up @@ -225,7 +225,7 @@
<configuration>
<rules>
<enforceBytecodeVersion>
<maxJdkVersion>11</maxJdkVersion>
<maxJdkVersion>17</maxJdkVersion>
Copy link
Copy Markdown

@coderabbitai coderabbitai bot Nov 4, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

Verify alignment with Jetty 12.1.0 minimum Java requirements.

The bytecode version enforcement has been updated to JDK 17, which aligns with Jetty 12.1.0's requirements. However, note that lines 43-44 still specify maven.compiler.source and maven.compiler.release as 11.

Please verify whether the compiler settings should also be updated to Java 17, or if the project intends to maintain Java 11 source compatibility while allowing Java 17 bytecode in dependencies:


🏁 Script executed:

#!/bin/bash
# Check if Jetty 12.1.0 requires Java 17 minimum
echo "Checking Jetty 12 requirements and current compiler settings..."

# Display current compiler settings
rg -n "maven\.compiler\.(source|release|target)" pom.xml lang/java/pom.xml

# Check for any other JDK version references
rg -n "maxJdkVersion|maven\.compiler" pom.xml

Length of output: 367


🌐 Web query:

Jetty 12.1.0 minimum Java version requirements

💡 Result:

Jetty 12.1.0 requires Java 17 (OpenJDK 17+) as the minimum; OpenJDK 21 is recommended for building/documentation. [1][2]

Sources:

  • Jetty 12 documentation (version table). [1]
  • Jetty build requirements (jetty-12.1.x: OpenJDK 17+; recommended OpenJDK 21). [2]

Update compiler settings to Java 17 to align with Jetty 12.1.0 requirements.

Jetty 12.1.0 requires Java 17 (OpenJDK 17+) as the minimum. The maxJdkVersion at line 228 is correctly set to 17, but the compiler settings at lines 43–44 still specify Java 11, creating a mismatch. Update maven.compiler.source and maven.compiler.release from 11 to 17:

<maven.compiler.source>17</maven.compiler.source>
<maven.compiler.release>17</maven.compiler.release>
🤖 Prompt for AI Agents
In pom.xml around lines 43–44 and 228, the project properties still set Java 11
while maxJdkVersion is 17; update the compiler properties to Java 17 by changing
maven.compiler.source and maven.compiler.release from 11 to 17 (and if present,
maven.compiler.target to 17) so the Maven compiler settings match Jetty 12.1.0’s
Java 17 requirement.

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

value:useful; category:bug; feedback:The AI agent is correct that the Java version should be changed from 11 to 17 if the project wants to accept this PR. But Avro is used in old codebases and its development is conservative. The bump to JDK 17 should be discussed first in the mailing lists.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@martin-augment, thank you for that important context! You're absolutely right that this is a significant breaking change for a foundational library like Avro.

Given that this PR updates Jetty to 12.1.0 (which requires Java 17) but also represents a major compatibility shift for downstream users, it would indeed be prudent to:

  1. Discuss on the mailing lists - The dev@avro.apache.org list would be the appropriate forum to discuss the impact of requiring Java 17 as the minimum version
  2. Check JIRA issue AVRO-4192 - There may already be discussion there about the Java version requirements
  3. Consider the migration path - Document the breaking change clearly and provide guidance for users who need to stay on Java 11

The technical requirements are clear (Jetty 12.1.0 requires Java 17), but you're right that the decision to proceed with this upgrade needs community consensus given Avro's widespread use in production systems that may not be ready to move to Java 17.

Would you like me to help draft a discussion thread for the mailing list, or is this already being discussed in AVRO-4192?


✏️ Learnings added
Learnt from: martin-augment
Repo: martin-augment/avro PR: 16
File: pom.xml:228-228
Timestamp: 2025-11-04T08:10:04.874Z
Learning: Apache Avro has a conservative development approach regarding Java version upgrades due to its widespread use in old codebases. Major version bumps (e.g., Java 11 to 17) should be discussed on the mailing lists (devavro.apache.org) before proceeding, even when technically required by dependency updates.

Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.

<ignoredScopes>
<ignoredScope>test</ignoredScope>
<ignoredScope>provided</ignoredScope>
Expand Down