Add Java 21 compile time support#1275
Conversation
|
Warning Rate limit exceeded
⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. WalkthroughAdds multiple new OSGi bundle Maven POMs, one Tiles Java class, a Tiles TLD, and a service loader entry registering Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
madurangasiriwardena
force-pushed
the
java21
branch
from
dc09e3c to
e0f085f
Compare
madurangasiriwardena
force-pushed
the
java21
branch
from
831cccb to
71d68b0
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 17
🤖 Fix all issues with AI agents
In `@abdera-jdk21/1.0.0.wso2v1/pom.xml`:
- Around line 114-117: The POM currently sets the Maven repository
<checksumPolicy> to "ignore" inside the <releases> block; change the
<checksumPolicy> value from "ignore" to a stricter option (e.g., "warn" or
"fail") to re-enable checksum verification for downloaded artifacts, updating
the <checksumPolicy> element in the same <releases> section accordingly so
artifact integrity is enforced.
In `@bctls/1.83.0.wso2v1/pom.xml`:
- Around line 30-32: Update the <description> element in the pom.xml to reflect
the correct bundle version (1.83.0) instead of the incorrect "TLS 1.80"; locate
the <description> tag that currently reads "This bundle will represent
bouncycastle TLS 1.80" and change the text to mention TLS 1.83 (e.g., "This
bundle will represent bouncycastle TLS 1.83.0") so the description matches the
pom version.
In `@csrfguard-jdk21/3.1.0.wso2v1/pom.xml`:
- Line 3: Update the copyright header in the added pom.xml so the year reflects
2025 instead of 2021: locate the copyright comment line containing "Copyright
(c) 2021, WSO2 Inc." and change the year to 2025 to reflect the current creation
date.
- Around line 61-65: The Import-Package negation pattern contains a typo:
replace the incorrect token "!org.owasp.csrfguardorg.*" in the Import-Package
element with the correct "!org.owasp.csrfguard.*" so the package negation
targets the intended org.owasp.csrfguard packages; update the string in the
pom.xml Import-Package entry accordingly.
- Around line 79-80: The pom properties javax.servlet.version and
javax.servlet.jsp.version declare ranges for the legacy javax.* API but don’t
clarify container compatibility with Java 21; update project docs and/or the pom
to explicitly state the required servlet container versions (e.g., note that
Tomcat 9 (or other Servlet 3.x containers) are supported with Java 21 while
Tomcat 10+/Jakarta EE 9+ are not compatible without migrating to
jakarta.servlet), and add a short comment near the javax.servlet.version and
javax.servlet.jsp.version properties (or README entry) that instructs users to
run on a javax-based container or migrate the codebase to jakarta.servlet before
using Tomcat 10+.
In `@encoder-jdk21/1.2.0.wso2v1/pom.xml`:
- Around line 33-46: The pom declares dependencies org.owasp.encoder:encoder and
org.owasp.encoder:encoder-jsp using the ${encoder.version} property; upgrade
that property to at least 1.3.1 (or 1.4.0) to remediate transitive CVEs in
encoder-jsp:1.2, and replace the encoder-jsp artifact with
org.owasp.encoder:encoder-jakarta-jsp if you want Jakarta servlet API
compatibility for Java 21—i.e., update the ${encoder.version} value and change
the artifactId from encoder-jsp to encoder-jakarta-jsp (or keep encoder-jsp but
with the bumped version).
- Around line 56-77: The maven-bundle-plugin version 2.3.7 in the <plugin> block
should be upgraded to a Java-21-compatible release: change the
<artifactId>maven-bundle-plugin</artifactId> <version> from 2.3.7 to 6.0.0 (or
later) in the plugin configuration so bndlib can parse Java 21 classfiles;
alternatively replace the maven-bundle-plugin block with a bnd-maven-plugin
configuration if you prefer migration — ensure the build environment uses JDK
17+ as required by the newer plugin.
In `@oltu-jdk21/1.0.0.wso2v1/pom.xml`:
- Around line 71-93: The maven-bundle-plugin configuration for the artifact
(maven-bundle-plugin block containing Export-Package and Import-Package) lacks
an Embed-Dependency instruction, so OLTU classes marked optional won’t be
packaged and Export-Package will be empty; add an Embed-Dependency entry to the
plugin's <instructions> that targets the OLTU artifacts (e.g., group/artifact
patterns for org.apache.oltu.*) and set appropriate embed-transformation (if
needed) and scope to ensure those dependencies are included in the bundle
alongside the existing Export-Package and Import-Package directives.
- Around line 34-52: The POM pulls in unmaintained Apache OLTU artifacts
(org.apache.oltu.oauth2.common, org.apache.oltu.oauth2.authzserver,
org.apache.oltu.oauth2.client) which transitively reference vulnerable org.json
(20131018) and your bundle relies on an OSGi-provided org.json ([3.0.0,4.0.0))
per Import-Package; to address this either replace/remove the OLTU dependencies
with a maintained OAuth2 library, or if you must keep them explicitly exclude
the transitive org.json from each OLTU dependency and add a dependencyManagement
override (or explicit safe org.json dependency) so the runtime receives a
patched org.json, and add a brief POM comment noting that OLTU is in Apache
Attic and is a security/maintenance risk.
- Around line 72-74: Update the Maven Bundle Plugin declaration by changing the
<version> for the plugin identified by groupId "org.apache.felix" and artifactId
"maven-bundle-plugin" from the old "1.4.0" to the current "6.0.0" so the build
uses the newer bndlib that can parse Java 21 classfiles; ensure the single
<version> element in the plugin block is updated and save the pom.xml.
In `@openid4java-jdk21/1.0.0.wso2v1/pom.xml`:
- Around line 3-10: Update the copyright year in the top XML comment block (the
multi-line comment containing "Copyright (c) 2022, WSO2 Inc.") to the current
year (e.g., 2025) or a year-range (e.g., "2022-2025") so the header reflects the
file's creation date; edit the comment that begins with "<!--" and contains
"WSO2 Inc." to replace "2022" accordingly.
- Around line 118-122: Update the maven-bundle-plugin declaration to a
Java-21-compatible release: change the <version> value for the
org.apache.felix:maven-bundle-plugin (the plugin block containing groupId
org.apache.felix and artifactId maven-bundle-plugin) from 1.4.0 to 6.0.0 so it
uses bndlib 7.x which supports Java 21 classfiles; ensure the existing
<extensions>true</extensions> and other plugin configuration remain unchanged.
In `@tiles-jdk21/3.0.7.wso2v1/pom.xml`:
- Around line 38-133: The pom declares vulnerable artifacts:
org.apache.tiles:tiles-core:3.0.7 (CVE-2023-49735 via
DefaultLocaleResolver.LOCALE_KEY) and transitive commons-beanutils via
commons-digester (affects PropertyUtilsBean, CVE-2025-48734); update the pom to
either (1) add an explicit exclusion for commons-beanutils (exclude groupId
commons-beanutils/artifactId commons-beanutils from the commons-digester
dependency or from tiles-core if it pulls it) or (2) document and accept the
risk and add README/SECURITY notes explaining runtime mitigations for
DefaultLocaleResolver.LOCALE_KEY (ensure no attacker-controlled input maps to
locale keys; implement allowlisting/validation of locale values) and for
PropertyUtilsBean (restrict deserialization/property access or upgrade if
possible), referencing the artifacts tiles-core, commons-digester,
commons-beanutils, DefaultLocaleResolver.LOCALE_KEY, and PropertyUtilsBean so
reviewers can locate the changes.
In `@tiles-jdk21/3.0.7.wso2v1/src/main/resources/META-INF/tiles-jsp.tld`:
- Around line 52-155: Fix the malformed example tags and typos in the TLD docs:
in the insertTemplate example replace the incorrect closing tag
"</tiles:insert>" with the matching "</tiles:insertTemplate>" and ensure the
tag's attributes are correctly quoted; in the insertDefinition example correct
the typo in the name attribute (e.g. "defininition" -> "definition"), add the
missing quote after the name value and ensure the opening tag ends with a ">"
and the example uses the proper closing tag "</tiles:insertDefinition>" so
examples are well-formed and consistent with tag names
InsertTemplate/insertTemplate and InsertDefinition/insertDefinition.
In `@waffle-jdk21/1.6.wso2v1/pom.xml`:
- Around line 1-2: Update the copyright header in pom.xml from 2022 to the
current year (2025 or 2026 as appropriate); locate the existing XML comment
block at the top of pom.xml (the multi-line comment starting with "<!--" that
contains "Copyright (c) 2022, WSO2 Inc.") and change the year to the correct one
so the header reflects the file creation/update year.
- Around line 47-60: The POM marks com.github.dblock.waffle:waffle-jna and
com.github.dblock.waffle:waffle-tomcat7 as optional but the maven-bundle-plugin
has no Embed-Dependency, so those classes won’t be packaged into the OSGi
bundle; fix by adding an Embed-Dependency (or remove the optional flags) in the
maven-bundle-plugin configuration to include waffle-jna and waffle-tomcat7 (or
only waffle-jna if JNA should be provided separately), ensuring the
Embed-Dependency pattern references the artifactIds and versions used and that
Export-Package has the classes available to export.
- Around line 75-78: The Export-Package currently lists com.sun.jna.* but the
waffle-jna dependency is marked optional (waffle-jna) and not embedded, so those
packages won't exist in the bundle; fix by either (A) remove the
<optional>true</optional> flag from the waffle-jna dependency and add an
<Embed-Dependency>waffle-jna</Embed-Dependency> entry to the maven-bundle-plugin
configuration so com.sun.jna.* is actually packaged and can be exported, or (B)
remove com.sun.jna.* from the <Export-Package> list (leave waffle.*
version="${project.version}" only) so you don't export packages that aren't
embedded.
🧹 Nitpick comments (5)
abdera-jdk21/1.0.0.wso2v1/pom.xml (1)
1-17: Update copyright year range.The copyright header shows 2005-2010, but this is a new file being added in 2025. Consider updating to reflect the current year.
waffle-jdk21/1.6.wso2v1/pom.xml (2)
111-120: No Java 21 compilation settings present.This POM lacks explicit Java version configuration, despite being part of the jdk21 module suite. While the module is named to indicate Java 21 support, it doesn't explicitly declare compiler source/target versions. Consider adding maven.compiler.source and maven.compiler.target properties set to 21 to ensure consistent Java 21 compilation across the project.
Suggested addition
<properties> <waffle.version>1.6</waffle.version> + <maven.compiler.source>21</maven.compiler.source> + <maven.compiler.target>21</maven.compiler.target> <org.slf4j.version>[1.6.0,2.0.0)</org.slf4j.version>
64-67: Consider upgrading maven-bundle-plugin to the latest version.Version 2.4.0 is quite old (released in June 2013). The latest version is 6.0.0 (released November 2024), which supports Java 21, requires JDK 17+ and Maven 3.8.1, and includes over a decade of bug fixes and improvements. At minimum, upgrade to 5.1.9 or newer.
openid4java-jdk21/1.0.0.wso2v1/pom.xml (1)
165-166: Remove unused properties.
openid4java.export.versionandnet.sourceforge.nekohtml.versionare defined but never referenced in this POM. The actual nekohtml dependency uses${nekohtml.version}(line 181).Suggested cleanup
<properties> <openid4java.version>1.0.0</openid4java.version> - <openid4java.export.version>1.0.0</openid4java.export.version> - <net.sourceforge.nekohtml.version>1.9.13</net.sourceforge.nekohtml.version> <code.google.imp.pkg.version.range>[1.3.0,1.4.0)</code.google.imp.pkg.version.range>oltu-jdk21/1.0.0.wso2v1/pom.xml (1)
1-2: Copyright year may need updating.The copyright header shows 2015, but this is a new file being created in 2025. Consider updating the year to reflect the current date.
📝 Suggested fix
<!-- - ~ Copyright (c) 2015, WSO2 Inc. (http://www.wso2.org) All Rights Reserved. + ~ Copyright (c) 2025, WSO2 LLC. (http://www.wso2.com) All Rights Reserved.
| <enabled>true</enabled> | ||
| <updatePolicy>daily</updatePolicy> | ||
| <checksumPolicy>ignore</checksumPolicy> | ||
| </releases> |
There was a problem hiding this comment.
Security concern: checksumPolicy set to ignore.
Setting checksumPolicy to ignore bypasses checksum verification for downloaded artifacts, which could allow corrupted or tampered artifacts to be used. Consider using warn or fail instead to maintain artifact integrity verification.
Proposed fix
<releases>
<enabled>true</enabled>
<updatePolicy>daily</updatePolicy>
- <checksumPolicy>ignore</checksumPolicy>
+ <checksumPolicy>warn</checksumPolicy>
</releases>🤖 Prompt for AI Agents
In `@abdera-jdk21/1.0.0.wso2v1/pom.xml` around lines 114 - 117, The POM currently
sets the Maven repository <checksumPolicy> to "ignore" inside the <releases>
block; change the <checksumPolicy> value from "ignore" to a stricter option
(e.g., "warn" or "fail") to re-enable checksum verification for downloaded
artifacts, updating the <checksumPolicy> element in the same <releases> section
accordingly so artifact integrity is enforced.
| <description> | ||
| This bundle will represent bouncycastle TLS 1.80 | ||
| </description> |
There was a problem hiding this comment.
Fix incorrect version in description.
The description states "TLS 1.80" but the bundle version is 1.83.0. This appears to be a copy-paste error from a previous version.
📝 Proposed fix
<description>
- This bundle will represent bouncycastle TLS 1.80
+ This bundle will represent bouncycastle TLS 1.83
</description>📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| <description> | |
| This bundle will represent bouncycastle TLS 1.80 | |
| </description> | |
| <description> | |
| This bundle will represent bouncycastle TLS 1.83 | |
| </description> |
🤖 Prompt for AI Agents
In `@bctls/1.83.0.wso2v1/pom.xml` around lines 30 - 32, Update the <description>
element in the pom.xml to reflect the correct bundle version (1.83.0) instead of
the incorrect "TLS 1.80"; locate the <description> tag that currently reads
"This bundle will represent bouncycastle TLS 1.80" and change the text to
mention TLS 1.83 (e.g., "This bundle will represent bouncycastle TLS 1.83.0") so
the description matches the pom version.
csrfguard-jdk21/3.1.0.wso2v1/pom.xml
Outdated
| @@ -0,0 +1,91 @@ | |||
| <?xml version="1.0" encoding="utf-8"?> | |||
| <!-- | |||
| ~ Copyright (c) 2021, WSO2 Inc. (http://wso2.com) All Rights Reserved. | |||
There was a problem hiding this comment.
Outdated copyright year.
The copyright year is 2021, but this is a new file being added in 2025 for Java 21 support. Consider updating to 2025.
🤖 Prompt for AI Agents
In `@csrfguard-jdk21/3.1.0.wso2v1/pom.xml` at line 3, Update the copyright header
in the added pom.xml so the year reflects 2025 instead of 2021: locate the
copyright comment line containing "Copyright (c) 2021, WSO2 Inc." and change the
year to 2025 to reflect the current creation date.
| <javax.servlet.version>[3.0.0,4.0.0)</javax.servlet.version> | ||
| <javax.servlet.jsp.version>[2.3.0,2.4.0)</javax.servlet.jsp.version> |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
OWASP CSRFGuard 3.1.0 jakarta.servlet javax.servlet dependency
💡 Result:
OWASP CSRFGuard 3.1.0 is built for the legacy Servlet API (javax.servlet), not Jakarta (jakarta.servlet). Its Maven metadata lists provided dependencies on javax.servlet:servlet-api:2.5 and javax.servlet.jsp:jsp-api:2.1. [1]
If you need Jakarta Servlet (e.g., Tomcat 10+/Jakarta EE 9+), use a “-jakarta” CSRFGuard release instead (e.g. org.owasp:csrfguard:4.5.0-jakarta), which depends on jakarta.servlet:jakarta.servlet-api. [2]
Dependencies:
<!-- javax.servlet (Servlet 2.5/3.x-era containers) -->
<dependency>
<groupId>org.owasp</groupId>
<artifactId>csrfguard</artifactId>
<version>3.1.0</version>
</dependency>
<!-- jakarta.servlet (Jakarta EE 9+/Tomcat 10+) -->
<dependency>
<groupId>org.owasp</groupId>
<artifactId>csrfguard</artifactId>
<version>4.5.0-jakarta</version>
</dependency>Notes
- Keep the servlet API as provided (your app server supplies it). [1][2]
Sources: [1] https://mvnrepository.com/artifact/org.owasp/csrfguard/3.1.0/dependencies [2] https://central.sonatype.com/artifact/org.owasp/csrfguard
🌐 Web query:
Java 21 compatibility javax.servlet packages
💡 Result:
javax.servlet.* is not a Java 21 issue—it’s a Java EE vs Jakarta EE namespace issue.
- Java 21 does not include Servlet APIs in the JDK. Your project must get them from your servlet container (Tomcat/Jetty/etc.) or a provided-scope dependency.
- If your code imports
javax.servlet.*, you must target Servlet 4.0 / Java EE 8 (e.g., Tomcat 9, which implements Servlet 4.0 and runs on Java 8+—so Java 21 is fine) [1].- Maven (compile against, but don’t bundle into the WAR):
[2]
<dependency> <groupId>javax.servlet</groupId> <artifactId>javax.servlet-api</artifactId> <version>4.0.1</version> <scope>provided</scope> </dependency>
- Maven (compile against, but don’t bundle into the WAR):
- If you’re using a Jakarta EE 9+ container (e.g., Tomcat 10+), the package is
jakarta.servlet.*, and you must update/recompile because the Servlet API package name changed fromjavax.servlettojakarta.servlet[3].- Maven:
[4]
<dependency> <groupId>jakarta.servlet</groupId> <artifactId>jakarta.servlet-api</artifactId> <version>5.0.0</version> <scope>provided</scope> </dependency>
- Tomcat also provides a migration tool / deploy-time conversion to help move apps from
javax.*tojakarta.*[3].
- Maven:
Framework hint: Spring 6 / Boot 3 require Jakarta (jakarta.*) and are intended for Tomcat 10+ / Jetty 11+ [5].
Sources:
[1] https://tomcat.apache.org/migration-9
[2] https://central.sonatype.com/artifact/javax.servlet/javax.servlet-api/4.0.1
[3] https://tomcat.apache.org/migration-10.html
[4] https://central.sonatype.com/artifact/jakarta.servlet/jakarta.servlet-api/5.0.0
[5] https://docs.spring.io/spring-framework/docs/6.0.5/reference/html/overview.html
🌐 Web query:
CSRFGuard 3.1.0 release notes dependencies
💡 Result:
For OWASP CSRFGuard 3.1.0 (published Nov 12, 2015), the dependency footprint is essentially “container-provided”:
- Compile dependencies: none (0) (mvnrepository.com)
- Provided dependencies (expected from your servlet container):
javax.servlet:servlet-api:2.5(mvnrepository.com)javax.servlet.jsp:jsp-api:2.1(mvnrepository.com)
Release-notes-wise: I wasn’t able to locate official “3.1.0 release notes” content from OWASP (the current project page focuses on later releases), and MavenRepository lists no changelog entries for 3.1.0 (“Changes (0)”). (owasp.org)
Citations:
- 1: https://mvnrepository.com/artifact/org.owasp/csrfguard/3.1.0-JS-1?utm_source=openai
- 2: https://mvnrepository.com/artifact/org.owasp/csrfguard/3.1.0-JS-1?utm_source=openai
- 3: https://mvnrepository.com/artifact/org.owasp/csrfguard/3.1.0-JS-1?utm_source=openai
- 4: https://owasp.org/www-project-csrfguard/?utm_source=openai
Clarify servlet container version requirement for Java 21 compatibility.
CSRFGuard 3.1.0 uses the legacy javax.servlet namespace (not Jakarta). Java 21 itself is compatible with javax.servlet packages—the actual constraint is the servlet container version. If running on Tomcat 9, Java 21 is supported and javax.servlet dependencies work without issue. If running on Tomcat 10+ or another Jakarta EE 9+ container, the codebase requires migration to jakarta.servlet namespace because CSRFGuard 3.1.0 will not be compatible. Confirm the target servlet container version and document whether Java 21 compatibility requires container version constraints.
🤖 Prompt for AI Agents
In `@csrfguard-jdk21/3.1.0.wso2v1/pom.xml` around lines 79 - 80, The pom
properties javax.servlet.version and javax.servlet.jsp.version declare ranges
for the legacy javax.* API but don’t clarify container compatibility with Java
21; update project docs and/or the pom to explicitly state the required servlet
container versions (e.g., note that Tomcat 9 (or other Servlet 3.x containers)
are supported with Java 21 while Tomcat 10+/Jakarta EE 9+ are not compatible
without migrating to jakarta.servlet), and add a short comment near the
javax.servlet.version and javax.servlet.jsp.version properties (or README entry)
that instructs users to run on a javax-based container or migrate the codebase
to jakarta.servlet before using Tomcat 10+.
| <dependencies> | ||
| <dependency> | ||
| <groupId>org.apache.tiles</groupId> | ||
| <artifactId>tiles-jsp</artifactId> | ||
| <version>${apache.tiles.version}</version> | ||
| <optional>true</optional> | ||
| </dependency> | ||
| <dependency> | ||
| <groupId>commons-digester</groupId> | ||
| <artifactId>commons-digester</artifactId> | ||
| <version>${commons.digester.version}</version> | ||
| <optional>true</optional> | ||
| </dependency> | ||
| <dependency> | ||
| <groupId>org.apache.tiles</groupId> | ||
| <artifactId>tiles-servlet</artifactId> | ||
| <version>3.0.7</version> | ||
| <optional>true</optional> | ||
| </dependency> | ||
|
|
||
| <dependency> | ||
| <groupId>org.apache.tiles</groupId> | ||
| <artifactId>tiles-extras</artifactId> | ||
| <version>3.0.7</version> | ||
| <optional>true</optional> | ||
| <exclusions> | ||
| <exclusion> | ||
| <groupId>org.apache.tiles</groupId> | ||
| <artifactId>tiles-request-mustache</artifactId> | ||
| </exclusion> | ||
| <exclusion> | ||
| <groupId>org.apache.tiles</groupId> | ||
| <artifactId>tiles-freemarker</artifactId> | ||
| </exclusion> | ||
| <exclusion> | ||
| <groupId>org.apache.tiles</groupId> | ||
| <artifactId>tiles-velocity</artifactId> | ||
| </exclusion> | ||
| <exclusion> | ||
| <groupId>org.apache.tiles</groupId> | ||
| <artifactId>tiles-el</artifactId> | ||
| </exclusion> | ||
| <exclusion> | ||
| <groupId>org.apache.tiles</groupId> | ||
| <artifactId>tiles-mvel</artifactId> | ||
| </exclusion> | ||
| <exclusion> | ||
| <groupId>org.apache.tiles</groupId> | ||
| <artifactId>tiles-ognl</artifactId> | ||
| </exclusion> | ||
| <exclusion> | ||
| <groupId>org.apache.tiles</groupId> | ||
| <artifactId>tiles-compat</artifactId> | ||
| </exclusion> | ||
| <exclusion> | ||
| <groupId>com.google.guava</groupId> | ||
| <artifactId>guava</artifactId> | ||
| </exclusion> | ||
| <exclusion> | ||
| <groupId>com.google.code.findbugs</groupId> | ||
| <artifactId>jsr305</artifactId> | ||
| </exclusion> | ||
| <exclusion> | ||
| <groupId>org.springframework</groupId> | ||
| <artifactId>spring-beans</artifactId> | ||
| </exclusion> | ||
| <exclusion> | ||
| <groupId>org.springframework</groupId> | ||
| <artifactId>spring-aop</artifactId> | ||
| </exclusion> | ||
| <exclusion> | ||
| <groupId>org.springframework</groupId> | ||
| <artifactId>spring-context</artifactId> | ||
| </exclusion> | ||
| <exclusion> | ||
| <groupId>org.springframework</groupId> | ||
| <artifactId>spring-core</artifactId> | ||
| </exclusion> | ||
| <exclusion> | ||
| <groupId>org.springframework</groupId> | ||
| <artifactId>spring-expression</artifactId> | ||
| </exclusion> | ||
| <exclusion> | ||
| <groupId>org.springframework</groupId> | ||
| <artifactId>spring-web</artifactId> | ||
| </exclusion> | ||
| </exclusions> | ||
| </dependency> | ||
|
|
||
|
|
||
| <dependency> | ||
| <groupId>org.apache.tiles</groupId> | ||
| <artifactId>tiles-core</artifactId> | ||
| <version>3.0.7</version> | ||
| <optional>true</optional> | ||
| </dependency> |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, let's locate and read the full pom.xml file
find . -path "*/tiles-jdk21/3.0.7.wso2v1/pom.xml" -type fRepository: wso2/orbit
Length of output: 88
🏁 Script executed:
# Also search for any pom.xml files matching the pattern
fd -t f "pom.xml" | grep -i tiles | head -20Repository: wso2/orbit
Length of output: 167
🌐 Web query:
CVE vulnerabilities Apache Tiles 3.0.7 security issues
💡 Result:
Apache Tiles 3.0.7 is known to be affected by the following published CVE:
- CVE-2023-49735 (CVSS 7.5 HIGH) – Path traversal due to missing validation of the session attribute
DefaultLocaleResolver.LOCALE_KEYwhile resolving XML definition files; this can lead to path traversal and potentially SSRF / XXE when attacker-controlled data is passed to that key. The advisory notes the project is “unsupported when assigned” (i.e., no longer supported/maintained). [1][2]- Affected versions include 3.0.7 (and broadly “version 2 onwards”). [1][3]
- No fixed version is available per multiple trackers/advisories. [2][4]
Practical mitigations (since there’s no patch):
- Ensure user input cannot influence
DefaultLocaleResolver.LOCALE_KEY(set it server-side only, or remove/disable that locale-setting behavior). [1][4] - If you must accept locale from users, strictly allowlist expected locale values (e.g.,
en,en_US) and reject any value containing path separators (/,\),.., URL schemes, etc. - Reduce blast radius: run the app with least-privilege filesystem permissions and restrict access to any Tiles XML definition resources.
Sources
- NVD entry for CVE-2023-49735 (description + “affects Apache Tiles from version 2 onwards” + unsupported note) [1]
- GitLab Advisory Database (no solution available) [2]
- OSV/GitHub advisory data listing affected versions including 3.0.7 [3]
- Snyk advisory noting no fixed version and the
DefaultLocaleResolver.LOCALE_KEYvector [4]
🌐 Web query:
Apache Commons BeanUtils 1.8.0 vulnerability CVE
💡 Result:
Apache Commons BeanUtils 1.8.0 is affected by these published CVEs:
- CVE-2014-0114 – BeanUtils does not suppress the
classproperty, enabling ClassLoader manipulation and potential arbitrary code execution when attacker-controlled property names are used (notably in Struts 1.x usage). Affects BeanUtils through 1.9.2. (ubuntu.com) - CVE-2019-10086 – Insecure deserialization / unsafe reflection exposure because the protective
BeanIntrospector(added in 1.9.2) was not enabled by default inPropertyUtilsBean, allowing access to the classloader via theclassproperty. Affects 1.0 through 1.9.3; patched in 1.9.4. (avd.aquasec.com) - CVE-2025-48734 – Improper access control:
PropertyUtilsBean/BeanUtilsBeanallowed access to an enum’sdeclaredClassproperty (and thus ClassLoader) when property paths are taken from an external/uncontrolled source. Affects BeanUtils 1.x before 1.11.0; fixed in 1.11.0 (and in 2.0.0-M2 forcommons-beanutils2). (nvd.nist.gov)
Upgrade guidance: for 1.x, upgrading to commons-beanutils 1.11.0+ addresses the latest issue (CVE-2025-48734) and is the safest target. (nvd.nist.gov)
Citations:
- 1: https://ubuntu.com/security/CVE-2014-0114?utm_source=openai
- 2: https://avd.aquasec.com/nvd/2019/cve-2019-10086/?utm_source=openai
- 3: https://nvd.nist.gov/vuln/detail/CVE-2025-48734?utm_source=openai
- 4: https://nvd.nist.gov/vuln/detail/CVE-2025-48734?utm_source=openai
🏁 Script executed:
cat -n ./tiles-jdk21/3.0.7.wso2v1/pom.xmlRepository: wso2/orbit
Length of output: 15045
🏁 Script executed:
# Search for commons-beanutils in the pom file
grep -i "beanutils" ./tiles-jdk21/3.0.7.wso2v1/pom.xmlRepository: wso2/orbit
Length of output: 36
🏁 Script executed:
# Check if there's a dependency tree or any mention of commons-beanutils
rg "commons-beanutils" --type xmlRepository: wso2/orbit
Length of output: 7946
🌐 Web query:
Apache Tiles 3.0.7 dependencies commons-beanutils transitive
💡 Result:
In Apache Tiles 3.0.7, commons-beanutils is pulled in transitively because tiles-core:3.0.7 depends on commons-digester:2.0 (compile scope). [1] Tiles’ published dependency report for tiles-core lists commons-beanutils:commons-beanutils:1.8.0 as a transitive compile dependency. [2] In practice, that means anything that brings in tiles-core (e.g., tiles-jsp:3.0.7) will also bring in BeanUtils transitively. [3]
If you want to remove it, exclude it where you declare Tiles (example for Maven):
<dependency>
<groupId>org.apache.tiles</groupId>
<artifactId>tiles-core</artifactId>
<version>3.0.7</version>
<exclusions>
<exclusion>
<groupId>commons-beanutils</groupId>
<artifactId>commons-beanutils</artifactId>
</exclusion>
</exclusions>
</dependency>Sources: [1] [2] [3]
🌐 Web query:
Apache Tiles core 3.0.7 pom.xml dependencies
💡 Result:
Apache Tiles tiles-core 3.0.7 declares these dependencies in its POM (scopes as shown):
<!-- compile -->
<dependency>
<groupId>commons-digester</groupId>
<artifactId>commons-digester</artifactId>
<version>2.0</version>
</dependency>
<dependency>
<groupId>org.apache.tiles</groupId>
<artifactId>tiles-api</artifactId>
<version>3.0.7</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jcl-over-slf4j</artifactId>
<version>1.7.6</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.6</version>
</dependency>
<!-- test -->
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>2.5</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.7</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.apache.shale</groupId>
<artifactId>shale-test</artifactId>
<version>1.0.5</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.easymock</groupId>
<artifactId>easymock</artifactId>
<version>3.0</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.easymock</groupId>
<artifactId>easymockclassextension</artifactId>
<version>3.0</version>
<scope>test</scope>
</dependency>[1] (mvnrepository.com)
Citations:
Address high-severity vulnerabilities in embedded dependencies.
org.apache.tiles:tiles-core:3.0.7 (pulled directly) is affected by CVE-2023-49735 (CVSS 7.5 HIGH—path traversal via DefaultLocaleResolver.LOCALE_KEY). The upstream project is unsupported; no patched version exists. Additionally, commons-beanutils:1.8.0 (transitive via commons-digester:2.0) carries multiple vulnerabilities including CVE-2025-48734 (improper access control in PropertyUtilsBean, affects 1.x before 1.11.0) and older CVEs (CVE-2019-10086, CVE-2014-0114).
Both vulnerabilities will be embedded in the final bundle. Consider:
- For commons-beanutils: Exclude it in the
tiles-coredependency (if not needed) or document that it requires strict runtime controls to prevent attacker-influenced property access. - For tiles-core: Document the path traversal mitigation—ensure user input cannot influence
DefaultLocaleResolver.LOCALE_KEYand apply allowlisting for locale values.
Confirm acceptance of these risks or implement exclusions/mitigations before release.
🤖 Prompt for AI Agents
In `@tiles-jdk21/3.0.7.wso2v1/pom.xml` around lines 38 - 133, The pom declares
vulnerable artifacts: org.apache.tiles:tiles-core:3.0.7 (CVE-2023-49735 via
DefaultLocaleResolver.LOCALE_KEY) and transitive commons-beanutils via
commons-digester (affects PropertyUtilsBean, CVE-2025-48734); update the pom to
either (1) add an explicit exclusion for commons-beanutils (exclude groupId
commons-beanutils/artifactId commons-beanutils from the commons-digester
dependency or from tiles-core if it pulls it) or (2) document and accept the
risk and add README/SECURITY notes explaining runtime mitigations for
DefaultLocaleResolver.LOCALE_KEY (ensure no attacker-controlled input maps to
locale keys; implement allowlisting/validation of locale values) and for
PropertyUtilsBean (restrict deserialization/property access or upgrade if
possible), referencing the artifacts tiles-core, commons-digester,
commons-beanutils, DefaultLocaleResolver.LOCALE_KEY, and PropertyUtilsBean so
reviewers can locate the changes.
| <p>You must specify <li><code>template</code> attribute, for inserting a template</p> | ||
|
|
||
| <p><strong>Example : </strong></p> | ||
| <pre> | ||
| <code> | ||
| <tiles:insertTemplate template="/basic/myLayout.jsp" flush="true"> | ||
| <tiles:put name="title" value="My first page" /> | ||
| <tiles:put name="header" value="/common/header.jsp" /> | ||
| <tiles:put name="footer" value="/common/footer.jsp" /> | ||
| <tiles:put name="menu" value="/basic/menu.jsp" /> | ||
| <tiles:put name="body" value="/basic/helloBody.jsp" /> | ||
| </tiles:insert> | ||
| </code> | ||
| </pre> | ||
| ]]> | ||
| </description> | ||
| <attribute> | ||
| <name>template</name> | ||
| <required>true</required> | ||
| <rtexprvalue>true</rtexprvalue> | ||
| <description> | ||
| <![CDATA[ | ||
| <p>A string representing the URI of a template (for example, a JSP | ||
| page). | ||
| </p> | ||
| ]]> | ||
| </description> | ||
| </attribute> | ||
| <attribute> | ||
| <name>flush</name> | ||
| <required>false</required> | ||
| <rtexprvalue>false</rtexprvalue> | ||
| <type>boolean</type> | ||
| <description> | ||
| <![CDATA[ | ||
| <p>True or false. If true, current page out stream is flushed | ||
| before insertion.</p> | ||
| ]]> | ||
| </description> | ||
| </attribute> | ||
| <attribute> | ||
| <name>ignore</name> | ||
| <required>false</required> | ||
| <rtexprvalue>true</rtexprvalue> | ||
| <type>boolean</type> | ||
| <description> | ||
| <![CDATA[ | ||
| <p>If this attribute is set to true, and the attribute specified by the | ||
| name does not exist, simply return without writing anything. The | ||
| default value is false, which will cause a runtime exception to be | ||
| thrown.</p> | ||
| ]]> | ||
| </description> | ||
| </attribute> | ||
| <attribute> | ||
| <name>role</name> | ||
| <required>false</required> | ||
| <rtexprvalue>true</rtexprvalue> | ||
| <description> | ||
| <![CDATA[ | ||
| <p>If the user is in the specified role, the tag is taken into account; | ||
| otherwise, the tag is ignored (skipped).</p> | ||
| ]]> | ||
| </description> | ||
| </attribute> | ||
|
|
||
| <attribute> | ||
| <name>preparer</name> | ||
| <required>false</required> | ||
| <rtexprvalue>true</rtexprvalue> | ||
| <description> | ||
| The fully qualified class name of the preparer. | ||
| </description> | ||
| </attribute> | ||
| </tag> | ||
| <tag> | ||
| <name>insertDefinition</name> | ||
| <tag-class>org.apache.tiles.jsp.taglib.InsertDefinitionTag</tag-class> | ||
| <body-content>JSP</body-content> | ||
| <description> | ||
| <![CDATA[ | ||
| <p><strong>Insert a definition.</strong></p> | ||
| <p>Insert a definition with the possibility to override and specify | ||
| parameters (called attributes). | ||
| A definition can be seen as a (partially or totally) filled template that | ||
| can override or complete attribute values. | ||
| <code><tiles:insertDefinition></code> allows to define these attributes | ||
| and pass them to the inserted jsp page, called template. | ||
| Attributes are defined using nested tag <code><tiles:put></code> or | ||
| <code><tiles:putList></code>. | ||
| </p> | ||
| <p>You must specify <code>name</code> tag attribute, for inserting a definition from | ||
| definitions factory.</p> | ||
| <p><strong>Example : </strong></p> | ||
| <pre> | ||
| <code> | ||
| <tiles:insertDefinition name=".my.tiles.defininition flush="true"> | ||
| <tiles:put name="title" value="My first page" /> | ||
| <tiles:put name="header" value="/common/header.jsp" /> | ||
| <tiles:put name="footer" value="/common/footer.jsp" /> | ||
| <tiles:put name="menu" value="/basic/menu.jsp" /> | ||
| <tiles:put name="body" value="/basic/helloBody.jsp" /> | ||
| </tiles:insertDefinition> | ||
| </code> |
There was a problem hiding this comment.
Fix malformed tag examples in the TLD docs.
The example snippets have a mismatched closing tag and a malformed insertDefinition example (typo + missing quote). These are user-facing and can cause confusion.
📝 Suggested doc corrections
- </tiles:insert>
+ </tiles:insertTemplate>
@@
- <tiles:insertDefinition name=".my.tiles.defininition flush="true">
+ <tiles:insertDefinition name=".my.tiles.definition" flush="true">🤖 Prompt for AI Agents
In `@tiles-jdk21/3.0.7.wso2v1/src/main/resources/META-INF/tiles-jsp.tld` around
lines 52 - 155, Fix the malformed example tags and typos in the TLD docs: in the
insertTemplate example replace the incorrect closing tag "</tiles:insert>" with
the matching "</tiles:insertTemplate>" and ensure the tag's attributes are
correctly quoted; in the insertDefinition example correct the typo in the name
attribute (e.g. "defininition" -> "definition"), add the missing quote after the
name value and ensure the opening tag ends with a ">" and the example uses the
proper closing tag "</tiles:insertDefinition>" so examples are well-formed and
consistent with tag names InsertTemplate/insertTemplate and
InsertDefinition/insertDefinition.
| <dependencies> | ||
| <dependency> | ||
| <groupId>com.github.dblock.waffle</groupId> | ||
| <artifactId>waffle-jna</artifactId> | ||
| <version>${waffle.version}</version> | ||
| <optional>true</optional> | ||
| </dependency> | ||
| <dependency> | ||
| <groupId>com.github.dblock.waffle</groupId> | ||
| <artifactId>waffle-tomcat7</artifactId> | ||
| <version>${waffle.version}</version> | ||
| <optional>true</optional> | ||
| </dependency> | ||
| </dependencies> |
There was a problem hiding this comment.
Missing Embed-Dependency instruction — bundle may be empty.
Both dependencies are marked as optional, but there's no Embed-Dependency instruction in the maven-bundle-plugin configuration. Without this, the waffle and JNA classes won't be included in the bundle, and the Export-Package directive will have nothing to export.
🐛 Proposed fix to embed dependencies
<Export-Package>
waffle.*;version="${project.version}",
com.sun.jna.*;version="${project.version}"
</Export-Package>
+ <Embed-Dependency>waffle-jna;scope=compile|runtime;inline=false,waffle-tomcat7;scope=compile|runtime;inline=false</Embed-Dependency>
<Private-Package>
</Private-Package>Alternatively, if JNA should come from a separate bundle:
+ <Embed-Dependency>waffle-jna,waffle-tomcat7;scope=compile|runtime</Embed-Dependency>🤖 Prompt for AI Agents
In `@waffle-jdk21/1.6.wso2v1/pom.xml` around lines 47 - 60, The POM marks
com.github.dblock.waffle:waffle-jna and com.github.dblock.waffle:waffle-tomcat7
as optional but the maven-bundle-plugin has no Embed-Dependency, so those
classes won’t be packaged into the OSGi bundle; fix by adding an
Embed-Dependency (or remove the optional flags) in the maven-bundle-plugin
configuration to include waffle-jna and waffle-tomcat7 (or only waffle-jna if
JNA should be provided separately), ensuring the Embed-Dependency pattern
references the artifactIds and versions used and that Export-Package has the
classes available to export.
| <Export-Package> | ||
| waffle.*;version="${project.version}", | ||
| com.sun.jna.*;version="${project.version}" | ||
| </Export-Package> |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, let's find the waffle bundle pom.xml and examine its full configuration
find . -path "*/waffle-jdk21/1.6.wso2v1/pom.xml" -type fRepository: wso2/orbit
Length of output: 87
🏁 Script executed:
# Search for JNA exports/bundling across the repository
rg "com\.sun\.jna" --glob "*.xml" -B 2 -A 2 | head -50Repository: wso2/orbit
Length of output: 2860
🏁 Script executed:
# Look for any JNA-specific OSGi bundles or bundles that already export JNA
rg -i "jna" --glob "*.xml" | grep -i "export\|bundle\|version" | head -30Repository: wso2/orbit
Length of output: 1356
🏁 Script executed:
# Read the full pom.xml for waffle-jdk21/1.6.wso2v1
cat -n ./waffle-jdk21/1.6.wso2v1/pom.xmlRepository: wso2/orbit
Length of output: 6719
🏁 Script executed:
# Also check the waffle (non-jdk21) version for comparison
cat -n ./waffle/1.6.wso2v7/pom.xmlRepository: wso2/orbit
Length of output: 6712
The bundle exports com.sun.jna.* packages that are not actually embedded.
The waffle-jna dependency is marked as <optional>true</optional> (line 52) without an <Embed-Dependency> instruction in the maven-bundle-plugin configuration. This means the JNA classes will not be packed into the bundle at all. Exporting com.sun.jna.* from lines 75-78 is therefore invalid—the packages do not exist in the resulting bundle.
To fix:
- Remove
<optional>true</optional>from the waffle-jna dependency and add an<Embed-Dependency>waffle-jna</Embed-Dependency>instruction to bundle it, OR - Remove
com.sun.jna.*from<Export-Package>since it cannot be exported if not embedded
🤖 Prompt for AI Agents
In `@waffle-jdk21/1.6.wso2v1/pom.xml` around lines 75 - 78, The Export-Package
currently lists com.sun.jna.* but the waffle-jna dependency is marked optional
(waffle-jna) and not embedded, so those packages won't exist in the bundle; fix
by either (A) remove the <optional>true</optional> flag from the waffle-jna
dependency and add an <Embed-Dependency>waffle-jna</Embed-Dependency> entry to
the maven-bundle-plugin configuration so com.sun.jna.* is actually packaged and
can be exported, or (B) remove com.sun.jna.* from the <Export-Package> list
(leave waffle.* version="${project.version}" only) so you don't export packages
that aren't embedded.
There was a problem hiding this comment.
Actionable comments posted: 5
🤖 Fix all issues with AI agents
In `@bcpg/1.83.0.wso2v1/pom.xml`:
- Around line 65-69: The maven-bundle-plugin version 3.5.0 in the plugin
declaration (org.apache.felix:maven-bundle-plugin) uses a bndlib that cannot
parse Java 21 classfiles; update the <version> element for the
maven-bundle-plugin to 6.0.0 or later (which embeds bndlib 7.x) in the plugin
block so the build can handle Java 21 bytecode, then run a quick build to verify
compatibility with the rest of the POM.
In `@oltu-jdk21/1.0.0.wso2v1/pom.xml`:
- Line 101: The declared Maven property org.json.version.range currently uses
semantic versioning "[3.0.0, 4.0.0)" which doesn't match org.json's date-based
tags; update the property org.json.version.range in the pom (the XML element
shown) to a date-based range such as "[20231013,20260101)" or another
appropriate YYYYMMDD-based upper bound to ensure OSGi/Maven resolves the real
org.json releases.
In `@openid4java-jdk21/1.0.0.wso2v1/pom.xml`:
- Around line 36-115: The openxri-syntax dependency (artifactId openxri-syntax)
is missing an exclusion for xerces:xercesImpl, allowing the vulnerable xerces to
be pulled in transitively; update the openxri-syntax <dependency> entry to add
an exclusion for groupId "xerces" and artifactId "xercesImpl" (matching the
exclusions used in openxri-client and nekohtml) so the xercesImpl transitive
dependency is excluded from the bundle.
In `@tiles-jdk21/3.0.7.wso2v1/pom.xml`:
- Around line 140-144: Update the maven-bundle-plugin to a version that supports
Java 21: change the plugin version for org.apache.felix:maven-bundle-plugin from
3.3.0 to 6.0.0 (or update the ${maven.bundle.plugin.version} property to
"6.0.0") so the build uses bndlib 7.x and can handle class file major version
65; ensure any pluginManagement or property declaration that defines
maven.bundle.plugin.version is also updated accordingly.
In `@waffle-jdk21/1.6.wso2v1/pom.xml`:
- Around line 64-67: The maven-bundle-plugin declared with groupId
org.apache.felix and artifactId maven-bundle-plugin is pinned to version 2.4.0
which embeds an ancient bndlib and cannot parse Java 21 class files; update the
plugin's <version> to 6.0.0 (or later) in the pom so it uses a modern bndlib
that supports Java 21, then run a full build to verify compatibility and adjust
any plugin configuration if warnings or new parameters are required by the newer
plugin.
🧹 Nitpick comments (1)
openid4java-jdk21/1.0.0.wso2v1/pom.xml (1)
174-175: Remove unused properties.The properties
openid4java.export.versionandnet.sourceforge.nekohtml.versionare defined but not referenced anywhere in this POM. The actual nekohtml version used isnekohtml.version(line 190).Suggested fix
<properties> <openid4java.version>1.0.0</openid4java.version> - <openid4java.export.version>1.0.0</openid4java.export.version> - <net.sourceforge.nekohtml.version>1.9.13</net.sourceforge.nekohtml.version> <code.google.imp.pkg.version.range>[1.3.0,1.4.0)</code.google.imp.pkg.version.range>
| <plugin> | ||
| <groupId>org.apache.felix</groupId> | ||
| <artifactId>maven-bundle-plugin</artifactId> | ||
| <version>3.5.0</version> | ||
| <extensions>true</extensions> |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
maven-bundle-plugin 3.5.0 Java 21 compatibility
💡 Result:
org.apache.felix:maven-bundle-plugin:3.5.0 is very unlikely to be Java 21–compatible for bytecode analysis.
- Version 3.5.0 was published 2018-01-06 and its dependency set includes
biz.aQute.bnd:biz.aQute.bndlib:3.5.0(the library that parses/analyzes class files to generate OSGi metadata). [1][2] - Java 21 produces class file major version 65. Tools/libraries that don’t understand that classfile version typically fail with “Unsupported class file major version 65”. [3]
Recommendation: Upgrade the Felix Maven Bundle Plugin to a much newer line (Central shows versions up to 6.0.0, published 2024-11-25) to pick up a newer bndlib with support for modern Java classfile versions. [4]
Sources
- Apache Felix bundle-plugin 3.5.0 “Plugin Documentation” (last published 2018-01-06) – https://felix.apache.org/documentation/_attachments/components/bundle-plugin-archives/bundle-plugin-3.5.0/plugin-info.html
- Apache Felix bundle-plugin 3.5.0 “Project Dependencies” (shows
biz.aQute.bndlib:3.5.0) – https://felix.apache.org/documentation/_attachments/components/bundle-plugin-archives/bundle-plugin-3.5.0/dependencies.html - Classfile major version table (65 = Java 21) – https://mkyong.com/java/java-unsupported-class-file-major-version-65/
- Maven Central directory for
maven-bundle-plugin(shows 6.0.0 and publish timestamp) – https://repo.maven.apache.org/maven2/org/apache/felix/maven-bundle-plugin/
🌐 Web query:
org.apache.felix maven-bundle-plugin Java 21 support minimum version
💡 Result:
Minimum org.apache.felix:maven-bundle-plugin version to use for Java 21 projects: 6.0.0 (released 2024-11-25). It upgrades the embedded bndlib from 6.3.1 → 7.0.0 [2] and the plugin itself requires JDK 17+ to run (so it runs fine on JDK 21) [1]. bnd 7.0.0 is the major line that moved to Java 17+ and added/expanded modern-JDK handling (for example multi-release JAR support) [3].
Sources:
[1] Apache Felix Maven Bundle Plugin docs (system requirements) (felix.apache.org)
[2] Maven Bundle Plugin 6.0.0 dependency change showing bndlib 7.0.0 (mvnrepository.com)
[3] bnd “Changes in 7.0.0” (Java 17 baseline; multi-release JAR support) (github.com)
Citations:
- 1: https://felix.apache.org/components/bundle-plugin/plugin-info.html?utm_source=openai
- 2: https://mvnrepository.com/artifact/org.apache.felix/maven-bundle-plugin/6.0.0/changes?utm_source=openai
- 3: https://github.com/bndtools/bnd/wiki/Changes-in-7.0.0
🌐 Web query:
maven-bundle-plugin release notes changelog Java 21
💡 Result:
Maven Bundle Plugin (org.apache.felix:maven-bundle-plugin) — release notes / changelog + Java 21 angle
Where to read the upstream changelog (release notes):
- The project maintains a
changelog.txtin the Felix dev repo (linked from ASF JIRA):tools/maven-bundle-plugin/changelog.txt. [1]
Key recent release relevant to Java 21 builds/runs:
- maven-bundle-plugin 6.0.0 (released 2024-11-25) upgrades its embedded bndlib from 6.3.1 → 7.0.0. [2]
- The Apache Felix plugin site also documents 6.0.0 as the current plugin version in its generated goal docs. [3]
Why that matters for Java 21:
- bnd 7.0.0 is a breaking release because it moved to Java 17, and it states it is updated to require Java 17 or later. [4]
So, running the Maven Bundle Plugin line that embeds bnd 7.x (e.g., maven-bundle-plugin 6.0.0) implies you must run Maven with Java ≥ 17—which includes Java 21.
Related note (release notes completeness):
- There was an ASF issue filed/resolved noting the maven-bundle-plugin 6.0.0 release notes didn’t mention the Java 17 requirement. [1]
Practical takeaway for “Java 21”
- If your goal is “works when Maven is run on Java 21”: use maven-bundle-plugin 6.0.0+ (since it embeds bnd 7.x, which requires Java 17+). [2][4]
Sources:
[1] ASF JIRA FELIX-6739 (points to changelog + Java requirement note) https://issues.apache.org/jira/browse/FELIX-6739
[2] mvnrepository “6.0.0 changes” (release date + bndlib 7.0.0) https://mvnrepository.com/artifact/org.apache.felix/maven-bundle-plugin/6.0.0/changes
[3] Apache Felix plugin docs (shows 6.0.0) https://felix.apache.org/components/bundle-plugin/bundle-mojo.html
[4] bnd wiki “Changes in 7.0.0” (Java 17 requirement) https://github.com/bndtools/bnd/wiki/Changes-in-7.0.0
Upgrade maven-bundle-plugin 3.5.0 — does not support Java 21 classfiles.
The bundled bndlib 3.5.0 cannot parse Java 21's class file major version 65. Upgrade to 6.0.0 or later, which embeds bndlib 7.0.0 with proper Java 21 bytecode support.
🤖 Prompt for AI Agents
In `@bcpg/1.83.0.wso2v1/pom.xml` around lines 65 - 69, The maven-bundle-plugin
version 3.5.0 in the plugin declaration (org.apache.felix:maven-bundle-plugin)
uses a bndlib that cannot parse Java 21 classfiles; update the <version> element
for the maven-bundle-plugin to 6.0.0 or later (which embeds bndlib 7.x) in the
plugin block so the build can handle Java 21 bytecode, then run a quick build to
verify compatibility with the rest of the POM.
| <oltu.version>1.0.0</oltu.version> | ||
| <javax.servlet.version.range>[3.1.0, 4.0.0)</javax.servlet.version.range> | ||
| <org.apache.commons.codec.version.range>[1.4.0,2.0.0)</org.apache.commons.codec.version.range> | ||
| <org.json.version.range>[3.0.0, 4.0.0)</org.json.version.range> |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check org.json available versions in Maven Central
curl -s "https://search.maven.org/solrsearch/select?q=g:org.json+AND+a:json&rows=100&wt=json" | jq '.response.docs | map({version: .v, timestamp: .timestamp}) | sort_by(.version) | reverse | .[0:30]'Repository: wso2/orbit
Length of output: 117
🌐 Web query:
org.json versioning scheme date-based semantic versioning
💡 Result:
org.json:json (JSON-java) does not use semantic versioning (SemVer). Instead, releases are labeled with a date-based version in the form:
YYYYMMDD(e.g.,20240303,20250517) — effectively “release date as the version.” [1], [2]
Rationale (per the project’s release docs):
- They intentionally avoid SemVer; historically the Maven releases have been by date, and changing the label format could cause mis-ordering in Maven repositories. [2]
So the “version comparison” is basically chronological: a larger YYYYMMDD means a newer release. [2], [3]
Sources: GitHub (JSON-java wiki) and Maven artifact listings. [2], [3], [1]
🏁 Script executed:
#!/bin/bash
# Get more detailed org.json version info from Maven Central
curl -s "https://search.maven.org/solrsearch/select?q=g:org.json+AND+a:json&rows=100&start=0&wt=json" | jq '.response.docs[] | {version: .v}' | head -50Repository: wso2/orbit
Length of output: 75
🏁 Script executed:
#!/bin/bash
# Also check the pom.xml file to see how version.range property is used
cd oltu-jdk21/1.0.0.wso2v1
if [ -f pom.xml ]; then
grep -n "org.json" pom.xml | head -20
fiRepository: wso2/orbit
Length of output: 208
🌐 Web query:
org.json maven central available versions releases
💡 Result:
For Maven Central artifact org.json:json, the currently published release versions are:
20070829, 20080701, 20090211, 20131018, 20140107, 20141113, 20150729, 20151123, 20160212, 20160807, 20160810, 20170516, 20171018, 20180130, 20180813, 20190722, 20200518, 20201115, 20210307, 20211205, 20220320, 20220924, 20230227, 20230618, 20231013, 20240205, 20240303, 20241224, 20250107, 20250517, 20251224. [1]
Latest release: 20251224 (published Dec 24, 2025). [1][2]
Maven dependency:
<dependency>
<groupId>org.json</groupId>
<artifactId>json</artifactId>
<version>20251224</version>
</dependency>Sources: [1] [2]
🌐 Web query:
org.json json-java latest version 3.0.0 4.0.0 releases
💡 Result:
- Artifact / coordinates (JSON-Java / org.json):
org.json:json(the JSON-Java project). - Latest release version (Maven Central):
20251224(published 2025‑12‑24). [1], [2] - Recent releases on Maven Central (newest → older):
20251224,20250517,20250107,20241224,20240303,20240205,20231013,20230618,20230227, … [1] - About “3.0.0” / “4.0.0” for org.json JSON-Java: those are not versions used by
org.json:jsonon Maven Central; JSON-Java uses date-based versions (YYYYMMDD) (as shown by the Maven Central directory and GitHub release tags like20241224,20240303, etc.). [1], [3]
Sources:
[1] https://repo1.maven.org/maven2/org/json/json/
[2] https://javadoc.io/doc/org.json/json/latest/index.html
[3] https://github.com/stleary/JSON-java/releases
Fix org.json version range to use actual date-based versions.
The org.json:json library uses date-based versioning (YYYYMMDD format, e.g., 20251224, 20240303, 20231013) and does not publish any semantic versions. The specified range [3.0.0, 4.0.0) does not match any actual org.json releases on Maven Central and will fail OSGi resolution at runtime. Update the version range to use a date-based format, for example [20231013, 20260101) or similar, depending on your compatibility requirements.
🤖 Prompt for AI Agents
In `@oltu-jdk21/1.0.0.wso2v1/pom.xml` at line 101, The declared Maven property
org.json.version.range currently uses semantic versioning "[3.0.0, 4.0.0)" which
doesn't match org.json's date-based tags; update the property
org.json.version.range in the pom (the XML element shown) to a date-based range
such as "[20231013,20260101)" or another appropriate YYYYMMDD-based upper bound
to ensure OSGi/Maven resolves the real org.json releases.
| <dependencies> | ||
| <dependency> | ||
| <groupId>org.openid4java</groupId> | ||
| <artifactId>openid4java</artifactId> | ||
| <version>${openid4java.version}</version> | ||
| <optional>true</optional> | ||
| </dependency> | ||
| <dependency> | ||
| <groupId>org.openxri</groupId> | ||
| <artifactId>openxri-client</artifactId> | ||
| <version>${openxri-client.version}</version> | ||
| <optional>true</optional> | ||
| <exclusions> | ||
| <exclusion> | ||
| <groupId>log4j</groupId> | ||
| <artifactId>log4j</artifactId> | ||
| </exclusion> | ||
| <exclusion> | ||
| <groupId>xalan</groupId> | ||
| <artifactId>xalan</artifactId> | ||
| </exclusion> | ||
| <exclusion> | ||
| <groupId>xerces</groupId> | ||
| <artifactId>xercesImpl</artifactId> | ||
| </exclusion> | ||
| <exclusion> | ||
| <groupId>org.slf4j</groupId> | ||
| <artifactId>slf4j-jcl</artifactId> | ||
| </exclusion> | ||
| <exclusion> | ||
| <groupId>jug</groupId> | ||
| <artifactId>jug</artifactId> | ||
| </exclusion> | ||
| <exclusion> | ||
| <groupId>xml-security</groupId> | ||
| <artifactId>xmlsec</artifactId> | ||
| </exclusion> | ||
| <exclusion> | ||
| <groupId>commons-logging</groupId> | ||
| <artifactId>commons-logging</artifactId> | ||
| </exclusion> | ||
| </exclusions> | ||
| </dependency> | ||
| <dependency> | ||
| <groupId>org.openxri</groupId> | ||
| <artifactId>openxri-syntax</artifactId> | ||
| <version>${openxri-syntax.version}</version> | ||
| <optional>true</optional> | ||
| <exclusions> | ||
| <exclusion> | ||
| <groupId>log4j</groupId> | ||
| <artifactId>log4j</artifactId> | ||
| </exclusion> | ||
| <exclusion> | ||
| <groupId>com.ibm.icu</groupId> | ||
| <artifactId>icu4j</artifactId> | ||
| </exclusion> | ||
| <exclusion> | ||
| <groupId>org.slf4j</groupId> | ||
| <artifactId>slf4j-jcl</artifactId> | ||
| </exclusion> | ||
| <exclusion> | ||
| <groupId>commons-logging</groupId> | ||
| <artifactId>commons-logging</artifactId> | ||
| </exclusion> | ||
| </exclusions> | ||
| </dependency> | ||
| <dependency> | ||
| <groupId>org.nokogiri</groupId> | ||
| <artifactId>nekohtml</artifactId> | ||
| <version>${nekohtml.version}</version> | ||
| <optional>true</optional> | ||
| <exclusions> | ||
| <exclusion> | ||
| <groupId>xerces</groupId> | ||
| <artifactId>xercesImpl</artifactId> | ||
| </exclusion> | ||
| </exclusions> | ||
| </dependency> | ||
| </dependencies> |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify xerces exclusions are effective
echo "=== File context: checking the actual pom.xml file ==="
if [ -f "openid4java-jdk21/1.0.0.wso2v1/pom.xml" ]; then
echo "Found pom.xml, examining lines 36-115:"
sed -n '36,115p' "openid4java-jdk21/1.0.0.wso2v1/pom.xml"
else
echo "File not found at expected location. Searching for pom.xml files..."
fd -name "pom.xml" -type f | head -10
fi
echo ""
echo "=== Searching for all xerces references in the file ==="
if [ -f "openid4java-jdk21/1.0.0.wso2v1/pom.xml" ]; then
rg -n "xerces" "openid4java-jdk21/1.0.0.wso2v1/pom.xml" -i
else
rg -n "xerces" . --type xml -i | head -20
fi
echo ""
echo "=== Checking for parent pom or dependency management ==="
if [ -f "openid4java-jdk21/1.0.0.wso2v1/pom.xml" ]; then
head -40 "openid4java-jdk21/1.0.0.wso2v1/pom.xml"
fiRepository: wso2/orbit
Length of output: 5108
🏁 Script executed:
#!/bin/bash
# Check the Embed-Dependency configuration and full dependency structure
echo "=== Checking Embed-Dependency configuration ==="
rg -n "Embed-Dependency" "openid4java-jdk21/1.0.0.wso2v1/pom.xml" -A 5 -B 2
echo ""
echo "=== Full pom.xml size and structure ==="
wc -l "openid4java-jdk21/1.0.0.wso2v1/pom.xml"
echo ""
echo "=== Checking Export-Package configuration around line 157 ==="
sed -n '150,170p' "openid4java-jdk21/1.0.0.wso2v1/pom.xml"
echo ""
echo "=== Verifying all dependency exclusion patterns ==="
rg -n "exclusion" "openid4java-jdk21/1.0.0.wso2v1/pom.xml" -B 2 -A 3 | head -80
echo ""
echo "=== Check if openxri-syntax has any xerces-related exclusions ==="
sed -n '73,89p' "openid4java-jdk21/1.0.0.wso2v1/pom.xml"Repository: wso2/orbit
Length of output: 5689
Add xerces:xercesImpl exclusion to openxri-syntax dependency.
The openxri-syntax dependency (lines 80-102) is embedded in the bundle but lacks an exclusion for xerces:xercesImpl. While openxri-client (line 58-59) and nekohtml (line 110-111) correctly exclude xerces, the missing exclusion on openxri-syntax is the likely transitive path allowing the vulnerable xerces:xercesImpl 2.8.1 to enter the bundle despite the Export-Package marking (line 157).
Add this exclusion to the openxri-syntax dependency:
<exclusion>
<groupId>xerces</groupId>
<artifactId>xercesImpl</artifactId>
</exclusion>🤖 Prompt for AI Agents
In `@openid4java-jdk21/1.0.0.wso2v1/pom.xml` around lines 36 - 115, The
openxri-syntax dependency (artifactId openxri-syntax) is missing an exclusion
for xerces:xercesImpl, allowing the vulnerable xerces to be pulled in
transitively; update the openxri-syntax <dependency> entry to add an exclusion
for groupId "xerces" and artifactId "xercesImpl" (matching the exclusions used
in openxri-client and nekohtml) so the xercesImpl transitive dependency is
excluded from the bundle.
| <plugin> | ||
| <groupId>org.apache.felix</groupId> | ||
| <artifactId>maven-bundle-plugin</artifactId> | ||
| <version>${maven.bundle.plugin.version}</version> | ||
| <extensions>true</extensions> |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
maven-bundle-plugin 3.3.0 Java 21 compatibility classfile
💡 Result:
org.apache.felix:maven-bundle-plugin:3.3.0 (released 2017-03-08) is not Java 21–classfile compatible when it needs to analyze/read .class files compiled for Java 21 (classfile major version 65). (repo1.maven.org)
In practice, with Java 21-built classes you’ll typically see errors like “Unsupported class file major version 65”, because that plugin line is based on an old bnd generation (circa 2016–2017). (mvnrepository.com)
What to do
- Upgrade
maven-bundle-pluginto a modern version (current major line is much newer than 3.3.0). (repo.maven.apache.org) - Or compile/target an older bytecode level (e.g.,
--release 17) so the older toolchain can read the classes. (mkyong.com)
Citations:
- 1: https://repo1.maven.org/maven2/org/apache/felix/maven-bundle-plugin/3.3.0/
- 2: https://mvnrepository.com/artifact/biz.aQute.bnd/bnd-maven-plugin/3.3.0?utm_source=openai
- 3: https://repo.maven.apache.org/maven2/org/apache/felix/maven-bundle-plugin/?utm_source=openai
- 4: https://mkyong.com/java/java-unsupported-class-file-major-version-65/?utm_source=openai
🌐 Web query:
org.apache.felix maven-bundle-plugin 6.x Java 21 support
💡 Result:
- Latest 6.x release (as of Feb 5, 2026): Maven Central shows 6.0.0 as the only 6.x version published. [2]
- Running on Java 21: The official plugin docs list minimum JDK = 17 (and Maven 3.8.1). So Java 21 is supported as a runtime (since it’s newer than 17). [1]
- Building/processing Java 21 bytecode:
maven-bundle-plugin6.0.0 updated its embedded bndlib to 7.0.0. Whether Java 21 classfile parsing works for your build therefore depends on that bndlib level (and its ASM/classfile support). [3]
Sources: [1] Apache Felix bundle plugin docs (system requirements), [2] Maven Central directory listing for org.apache.felix:maven-bundle-plugin, [3] 6.0.0 dependency change report (bndlib 7.0.0).
🌐 Web query:
bnd Java 21 classfile format version compatibility
💡 Result:
- Java 21 class files use major version
65(so tools that parse bytecode must understand classfile version 65). [1] - bnd/bndtools 7.x runs on Java 17+ (7.0.0 moved the code base to Java 17; 7.2.0 reiterates “all Bnd artifacts are built to run on Java 17 or later”). If you’re on older bnd (notably the Java-8 “classic” line), you’re more likely to hit “unsupported class file major version 65” when analyzing Java 21 bytecode. [2][3]
- Practical compatibility guidance:
- If you need to build/analyze Java 21-compiled bundles, upgrade to a current bnd/bndlib/bnd-maven/gradle plugin (7.2.x) rather than older 6.x/early 7.x. [3]
- Separately, ensure the JVM you run bnd/bndtools on is ≥ 17 (even if your bundles target 21). [2][3]
Sources:
[1] Atlassian KB (class file major versions table: Java 21 → 65) https://support.atlassian.com/bamboo/kb/bamboo-data-center-upgrade-fails-with-the-error-percent22this-version-of-the-java-runtime-only-recognizes-class-file-versions-up-to-xxpercent22/
[2] bnd wiki “Changes in 7.0.0” (moved code base to Java 17) https://github.com/bndtools/bnd/wiki/Changes-in-7.0.0
[3] bnd wiki “Changes in 7.2.0” (backward compatibility: Java 17+) https://github.com/bndtools/bnd/wiki/Changes-in-7.2.0
Upgrade maven-bundle-plugin from 3.3.0 to 6.0.0 to support Java 21.
The plugin version 3.3.0 (released 2017) is incompatible with Java 21 classfiles (major version 65) and will fail with "Unsupported class file major version 65" errors. Upgrade to 6.0.0, which includes bndlib 7.0.0 with full Java 21 bytecode support.
🤖 Prompt for AI Agents
In `@tiles-jdk21/3.0.7.wso2v1/pom.xml` around lines 140 - 144, Update the
maven-bundle-plugin to a version that supports Java 21: change the plugin
version for org.apache.felix:maven-bundle-plugin from 3.3.0 to 6.0.0 (or update
the ${maven.bundle.plugin.version} property to "6.0.0") so the build uses bndlib
7.x and can handle class file major version 65; ensure any pluginManagement or
property declaration that defines maven.bundle.plugin.version is also updated
accordingly.
| <plugin> | ||
| <groupId>org.apache.felix</groupId> | ||
| <artifactId>maven-bundle-plugin</artifactId> | ||
| <version>2.4.0</version> |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
maven-bundle-plugin Java 21 compatibility minimum version requirements
💡 Result:
For Java 21 projects, the practical minimum to use org.apache.felix:maven-bundle-plugin is:
maven-bundle-plugin 6.0.0(or newer) — it upgrades the embedded bndlib to 7.0.0 (from 6.3.1 in 5.1.9), which is the key step for handling newer classfile/tooling expectations. [2]- Run the plugin with at least JDK 17 (plugin “System Requirements” list JDK 17 minimum). Using JDK 21 to run Maven is also fine. [1]
- Context: bnd 7.x is the Java-17-based line (“Java release version is 17”). [3]
So: maven-bundle-plugin >= 6.0.0, Maven on JDK >= 17 (JDK 21 OK). [1][2][3]
Sources
[1] Apache Felix Maven Bundle Plugin docs – System Requirements (JDK 17) https://felix.apache.org/components/bundle-plugin/plugin-info.html
[2] mvnrepository “changes” for maven-bundle-plugin 6.0.0 (bndlib 7.0.0) https://mvnrepository.com/artifact/org.apache.felix/maven-bundle-plugin/6.0.0/changes
[3] bndtools/bnd README (bnd 7 / Java release version 17) https://github.com/bndtools/bnd
🌐 Web query:
apache felix maven-bundle-plugin version history Java 21 support
💡 Result:
Latest Apache Felix maven-bundle-plugin (as of Feb 5, 2026)
Maven Central shows 6.0.0 as the most recent release (2024-11-25). [1]
Version history (high-level)
Maven Central directory listing shows these release lines (selected milestones): 1.x (2007–2008), 2.x (2009–2015), 3.x (2015–2018), 4.x (2018–2019), 5.1.x (2020–2023), 6.0.0 (2024-11-25). [2]
Java 21 support (what it means in practice)
- Running the plugin on Java 21:
maven-bundle-plugin6.0.0 requires JDK 17 (minimum), so it is compatible with running on Java 21 (since 21 ≥ 17). [3] - Handling Java 21 bytecode / features:
maven-bundle-plugin6.0.0 upgrades to bndlib 7.0.0. [4] Bnd 7.0.0 moved to / requires Java 17. [5] (Bnd’s Java-21-bytecode parsing support is tied to its internal bytecode stack; if you’re specifically hitting “Unsupported class file major version 65”, share the exact error + plugin version and I can pinpoint the minimum bnd/bundle-plugin version needed.)
Sources:
[1] Maven Central 6.0.0 artifact directory timestamp (2024-11-25) https://repo1.maven.org/maven2/org/apache/felix/maven-bundle-plugin/6.0.0/
[2] Maven Central directory listing for all versions https://repo.maven.apache.org/maven2/org/apache/felix/maven-bundle-plugin/
[3] Felix plugin docs: system requirements for 6.0.0 (JDK 17) https://felix.apache.org/components/bundle-plugin/plugin-info.html
[4] 6.0.0 dependency change (bndlib 7.0.0) https://mvnrepository.com/artifact/org.apache.felix/maven-bundle-plugin/6.0.0/changes
[5] Bnd 7.0.0 release notes: moved to Java 17 https://github.com/bndtools/bnd/wiki/Changes-in-7.0.0
🌐 Web query:
maven-bundle-plugin 2.4.0 Java 21 bytecode compatibility
💡 Result:
org.apache.felix:maven-bundle-plugin:2.4.0 is not Java 21 bytecode–compatible in practice, because it embeds bndlib 2.1.0 (from 2013) as its bytecode analyzer/manipulator dependency. [1] Java 21 class files use major version 65, which older bytecode tools typically can’t parse and will fail with “unsupported class file major version 65”. [2]
What to do
- Upgrade the plugin: the current major line is maven-bundle-plugin 6.0.0 (Nov 25, 2024). [3]
- If you’re stuck on 2.4.0 for some reason, the only realistic workaround is to override the embedded bndlib to a modern version (7.x), but upgrading the plugin is the safer path.
Citations: [1] [2] [3]
Upgrade maven-bundle-plugin to version 6.0.0 or later for Java 21 compatibility.
The current version 2.4.0 is incompatible with Java 21 bytecode. It embeds bndlib 2.1.0 (from 2013), which cannot parse Java 21's class file major version 65. This will cause the build to fail when compiling with Java 21. Upgrade to maven-bundle-plugin 6.0.0 (the current release as of November 2024), which uses bndlib 7.0.0 and properly supports Java 21 bytecode.
🤖 Prompt for AI Agents
In `@waffle-jdk21/1.6.wso2v1/pom.xml` around lines 64 - 67, The
maven-bundle-plugin declared with groupId org.apache.felix and artifactId
maven-bundle-plugin is pinned to version 2.4.0 which embeds an ancient bndlib
and cannot parse Java 21 class files; update the plugin's <version> to 6.0.0 (or
later) in the pom so it uses a modern bndlib that supports Java 21, then run a
full build to verify compatibility and adjust any plugin configuration if
warnings or new parameters are required by the newer plugin.
3 participants
Summary by CodeRabbit
New Features
Bug Fixes