Conversation
WalkthroughThis change introduces a new Maven OSGi bundle module for Apache Solr 10.0.0 (wso2v1 distribution) with comprehensive dependency management covering Solr 10 components, Jetty 12, OpenTelemetry, Jersey, ZooKeeper, Curator, Jackson, Lucene 10.3.2, and supporting libraries. OSGi bundle configuration includes package exports/imports and Lucene dependency shading. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~30 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (2)
solr/10.0.0.wso2v1/pom.xml (2)
532-536: Inconsistent<optional>marker on lucene-spatial-extras.All other Lucene modules are marked
<optional>true</optional>, butlucene-spatial-extrasis not. If this is intentional (i.e., it's a required dependency), this is fine. Otherwise, add the optional marker for consistency.Proposed fix if this should be optional
<dependency> <groupId>org.apache.lucene</groupId> <artifactId>lucene-spatial-extras</artifactId> <version>${version.lucene}</version> + <optional>true</optional> </dependency>🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@solr/10.0.0.wso2v1/pom.xml` around lines 532 - 536, The dependency for lucene-spatial-extras is missing the optional marker; update the dependency block for artifactId lucene-spatial-extras to include <optional>true</optional> to match the other Lucene modules (i.e., add the optional element under the dependency for org.apache.lucene:lucene-spatial-extras), or explicitly confirm and document if it must remain non-optional.
699-724: Upgrade maven-shade-plugin from 2.4 to 3.6.2 (latest stable version).Version 2.4 is from 2015 and is significantly outdated. The current stable version includes security fixes, better resource handling, and improved compatibility with modern Java versions.
Proposed fix
<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-shade-plugin</artifactId> - <version>2.4</version> + <version>3.6.2</version>🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@solr/10.0.0.wso2v1/pom.xml` around lines 699 - 724, Update the maven-shade-plugin version element from 2.4 to 3.6.2 in the plugin declaration for org.apache.maven.plugins:maven-shade-plugin; after changing <version> to 3.6.2, run a full build and verify the existing configuration keys and transformers (e.g., ServicesResourceTransformer and ApacheNoticeResourceTransformer, and flags like createSourcesJar, shadedArtifactAttached, promoteTransitiveDependencies, createDependencyReducedPom) remain compatible with the 3.x plugin and adjust any deprecated option names if build warnings/errors appear.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@solr/10.0.0.wso2v1/pom.xml`:
- Around line 240-244: The pom currently pins the jersey-container-jetty-http
dependency (artifactId: jersey-container-jetty-http) to an older Jersey 2.x
version via the property jersey.container.jetty.version causing a namespace
mismatch; update that dependency to Jersey 3.1.11 (set the
jersey-container-jetty-http version to 3.1.11 or align the
jersey.container.jetty.version property to 3.1.11), ensure any Embed-Dependency
entries that referenced the old Jetty integration are updated/removed, and
delete the now-unused jersey.container.jetty.version property so all Jersey
artifacts (Jersey 3.x) consistently use the jakarta.* namespace; apply the same
change where the same dependency appears elsewhere.
- Around line 285-305: The pom currently depends on ZooKeeper artifacts
org.apache.zookeeper:zookeeper and org.apache.zookeeper:zookeeper-jute using the
property ${version.zookeeper} which is set to a vulnerable 3.9.4; update that
property to 3.9.5 (or later) so both zookeeper and zookeeper-jute resolve to
3.9.5 to mitigate CVE-2026-24281 and CVE-2026-24308, then run a build to verify
dependency resolution and any needed compatibility changes for
curator-framework/curator-client references to ${curator.version}.
- Around line 418-423: The pom declares the vulnerable dependency
com.jayway.jsonpath:json-path using the property ${json.path.version}; bump this
to 2.10.0 or later so its transitive net.minidev:json-smart is upgraded to
2.6.0. Locate the json-path dependency (artifactId json-path / groupId
com.jayway.jsonpath) and update the ${json.path.version} property (or the
explicit <version> element) to "2.10.0" or a newer safe release, then run a
build to verify the updated transitive json-smart version.
---
Nitpick comments:
In `@solr/10.0.0.wso2v1/pom.xml`:
- Around line 532-536: The dependency for lucene-spatial-extras is missing the
optional marker; update the dependency block for artifactId
lucene-spatial-extras to include <optional>true</optional> to match the other
Lucene modules (i.e., add the optional element under the dependency for
org.apache.lucene:lucene-spatial-extras), or explicitly confirm and document if
it must remain non-optional.
- Around line 699-724: Update the maven-shade-plugin version element from 2.4 to
3.6.2 in the plugin declaration for org.apache.maven.plugins:maven-shade-plugin;
after changing <version> to 3.6.2, run a full build and verify the existing
configuration keys and transformers (e.g., ServicesResourceTransformer and
ApacheNoticeResourceTransformer, and flags like createSourcesJar,
shadedArtifactAttached, promoteTransitiveDependencies,
createDependencyReducedPom) remain compatible with the 3.x plugin and adjust any
deprecated option names if build warnings/errors appear.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: f39d2166-5968-4389-a767-7521a160d037
📒 Files selected for processing (1)
solr/10.0.0.wso2v1/pom.xml
| <dependency> | ||
| <groupId>org.glassfish.jersey.containers</groupId> | ||
| <artifactId>jersey-container-jetty-http</artifactId> | ||
| <version>${jersey.container.jetty.version}</version> | ||
| </dependency> |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Does Jersey 3.1.11 have jersey-container-jetty12-http artifact for Jetty 12 support?
💡 Result:
No, Jersey 3.1.11 does not have a jersey-container-jetty12-http artifact specifically for Jetty 12 support. The available artifact is jersey-container-jetty-http 3.1.11, which provides Jetty Http Container support (noted as for JDK 17+ in docs). This single multi-release JAR supports Jetty 12 via updates merged in PRs like #5372 (Jetty 12 multirelease, milestone 3.1.4) and #5481 (Jetty 12 HTTP/2 support, milestone 3.1.5), included in 3.1.11. Official docs list only jersey-container-jetty-http under Jersey Containers, with no separate -jetty12-http variant. Maven Central confirms jersey-container-jetty-http/3.1.11 exists, but no jersey-container-jetty12-http.
Citations:
- 1: https://central.sonatype.com/artifact/org.glassfish.jersey.containers/jersey-container-jetty-http/3.1.11
- 2: https://repo1.maven.org/maven2/org/glassfish/jersey/containers/jersey-container-jetty-http/3.1.11/
- 3: https://eclipse-ee4j.github.io/jersey.github.io/documentation/latest31x/index.html
- 4: https://eclipse-ee4j.github.io/jersey.github.io/documentation/latest31x/modules-and-dependencies.html
- 5: Unable to integrate Jersey with Jetty Embedded server eclipse-ee4j/jersey#5434
- 6: Jetty 12 multirelease eclipse-ee4j/jersey#5372
- 7: [3.1] Jetty 12 HTTP/2 support eclipse-ee4j/jersey#5481
- 8: https://github.com/eclipse-ee4j/jersey/releases
Critical: Jersey version mismatch will cause runtime failures.
jersey-container-jetty-http is pinned to version 2.39.1 (Jersey 2.x, javax.* namespace) while all other Jersey dependencies use version 3.1.11 (Jersey 3.x, jakarta.* namespace). Mixing these versions will cause ClassNotFoundException or NoClassDefFoundError at runtime due to incompatible package namespaces.
Update to jersey-container-jetty-http:3.1.11, which has integrated Jetty 12 support via multi-release JAR (JDK 17+).
Proposed fix
<dependency>
<groupId>org.glassfish.jersey.containers</groupId>
<artifactId>jersey-container-jetty-http</artifactId>
- <version>${jersey.container.jetty.version}</version>
+ <version>${jersey.version}</version>
</dependency>And update the Embed-Dependency:
- jersey-container-jetty-http;scope=compile|runtime;inline=false,
+ jersey-container-jetty-http;scope=compile|runtime;inline=false,Remove the now-unused property:
- <jersey.container.jetty.version>2.39.1</jersey.container.jetty.version>Also applies to: 739-740
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@solr/10.0.0.wso2v1/pom.xml` around lines 240 - 244, The pom currently pins
the jersey-container-jetty-http dependency (artifactId:
jersey-container-jetty-http) to an older Jersey 2.x version via the property
jersey.container.jetty.version causing a namespace mismatch; update that
dependency to Jersey 3.1.11 (set the jersey-container-jetty-http version to
3.1.11 or align the jersey.container.jetty.version property to 3.1.11), ensure
any Embed-Dependency entries that referenced the old Jetty integration are
updated/removed, and delete the now-unused jersey.container.jetty.version
property so all Jersey artifacts (Jersey 3.x) consistently use the jakarta.*
namespace; apply the same change where the same dependency appears elsewhere.
| <!-- ZooKeeper and Curator --> | ||
| <dependency> | ||
| <groupId>org.apache.zookeeper</groupId> | ||
| <artifactId>zookeeper</artifactId> | ||
| <version>${version.zookeeper}</version> | ||
| </dependency> | ||
| <dependency> | ||
| <groupId>org.apache.zookeeper</groupId> | ||
| <artifactId>zookeeper-jute</artifactId> | ||
| <version>${version.zookeeper}</version> | ||
| </dependency> | ||
| <dependency> | ||
| <groupId>org.apache.curator</groupId> | ||
| <artifactId>curator-framework</artifactId> | ||
| <version>${curator.version}</version> | ||
| </dependency> | ||
| <dependency> | ||
| <groupId>org.apache.curator</groupId> | ||
| <artifactId>curator-client</artifactId> | ||
| <version>${curator.version}</version> | ||
| </dependency> |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Apache ZooKeeper 3.9.4 security vulnerabilities patched version
💡 Result:
Apache ZooKeeper 3.9.4 has known security vulnerabilities, including CVE-2025-58457 (insufficient permission check in AdminServer, affecting 3.9.0 to <3.9.4) and CVE-2026-24308 (sensitive information disclosure in client configuration handling, affecting 3.9.0 through 3.9.4). The version that patches these vulnerabilities is Apache ZooKeeper 3.9.5. Upgrade to 3.9.5 or later (current release as of 2026-03-24). Note that 3.9.4 also inherits some third-party dependency CVEs (e.g., in Netty, Jetty), which are addressed in subsequent releases like 3.9.5.
Citations:
- 1: https://www.tenable.com/plugins/nessus/301977
- 2: https://zookeeper.apache.org/security.html
- 3: https://zookeeper.apache.org/doc/r3.9.4/releasenotes.html
- 4: https://zookeeper.apache.org/doc/r3.9.5/releasenotes.html
- 5: http://zookeeper.apache.org/releases.html
- 6: https://cve.akaoma.com/cve-2026-24308
- 7: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2026-24308
- 8: http://zookeeper.apache.org/security.html
🏁 Script executed:
# Find the actual ZooKeeper version in the pom.xml file
cd solr/10.0.0.wso2v1
grep -n "version.zookeeper" pom.xml | head -20Repository: wso2/orbit
Length of output: 222
🏁 Script executed:
# Search for the ZooKeeper version property definition
cd solr/10.0.0.wso2v1
grep -rn "zookeeper" pom.xml | grep -i "version\|property" | head -30Repository: wso2/orbit
Length of output: 222
🌐 Web query:
GHSA-7xrh-hqfc-g7qr ZooKeeper vulnerability
💡 Result:
GHSA-7xrh-hqfc-g7qr is a high-severity vulnerability (CVSS 3.1: 7.4) in Apache ZooKeeper, also tracked as CVE-2026-24281 and ZOOKEEPER-4986. It affects versions 3.8.0 to 3.8.5 and 3.9.0 to 3.9.4. The issue is in ZooKeeper's ZKTrustManager during TLS hostname verification. When IP Subject Alternative Name (SAN) validation fails, it falls back to reverse DNS (PTR record) lookup. Attackers controlling or spoofing PTR records can impersonate ZooKeeper servers or clients if they have a valid certificate trusted by ZKTrustManager. Exploitation requires network access, high attack complexity (controlling DNS PTR and possessing trusted cert), no privileges or user interaction needed. No known public exploits. Fix: Upgrade to 3.8.6 or 3.9.5, which add config options to disable reverse DNS fallback (e.g., ssl.hostnameVerification.reverseLookup=false). Official announcement: Apache mailing list March 2026. GitHub advisory: GHSA-7xrh-hqfc-g7qr. Patch: apache/zookeeper@66c4efe.
Citations:
- 1: https://www.resolvedsecurity.com/vulnerability-catalog/CVE-2026-24281
- 2: https://mondoo.com/vulnerability-intelligence/vulnerability/GHSA-7xrh-hqfc-g7qr
- 3: https://osv.dev/vulnerability/GHSA-7xrh-hqfc-g7qr
- 4: https://nvd.nist.gov/vuln/detail/cve-2026-24281
- 5: http://www.mail-archive.com/announce@apache.org/msg10789.html
🌐 Web query:
GHSA-crhr-qqj8-rpxc ZooKeeper vulnerability
💡 Result:
GHSA-crhr-qqj8-rpxc is a high-severity vulnerability (CVSS 4.0: 8.7 HIGH; CVSS 3.1: 7.5 HIGH) in Apache ZooKeeper, also tracked as CVE-2026-24308. It involves improper handling of configuration values in the ZKConfig component (CWE-532: Insertion of Sensitive Information into Log File). Affected versions: Apache ZooKeeper 3.8.0 through 3.8.5 and 3.9.0 through 3.9.4 (all platforms). Impact: Sensitive information from client configurations (e.g., credentials) is logged at INFO level in client logfiles, potentially exposing data in production environments where INFO logging is enabled and logs are accessible. Published: March 7, 2026. Fixed in: 3.8.6 and 3.9.5. Mitigation: Upgrade to 3.8.6 or 3.9.5. Review and sanitize existing logs; restrict log access. Official references: Apache announcement (https://lists.apache.org/thread/qng3rtzv2pqkmko4rhv85jfplkyrgqdr), NVD (https://nvd.nist.gov/vuln/detail/CVE-2026-24308), GitHub Advisory (GHSA-crhr-qqj8-rpxc), ZooKeeper security page (https://zookeeper.apache.org/security.html).
Citations:
- 1: https://mondoo.com/vulnerability-intelligence/vulnerability/GHSA-crhr-qqj8-rpxc
- 2: https://advisories.gitlab.com/pkg/maven/org.apache.zookeeper/zookeeper/CVE-2026-24308/
- 3: https://ossindex.sonatype.org/vulnerability/CVE-2026-24308?component-name=org.apache.zookeeper%2Fzookeeper&component-type=maven
- 4: https://osv.dev/vulnerability/GHSA-crhr-qqj8-rpxc
- 5: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2026-24308
- 6: https://www.resolvedsecurity.com/vulnerability-catalog/CVE-2026-24308
- 7: http://zookeeper.apache.org/security.html
Upgrade ZooKeeper from 3.9.4 to 3.9.5 to address two confirmed HIGH severity vulnerabilities.
ZooKeeper 3.9.4 contains:
- GHSA-7xrh-hqfc-g7qr (CVE-2026-24281): Reverse-DNS fallback in ZKTrustManager enables hostname verification bypass, allowing potential server/client impersonation.
- GHSA-crhr-qqj8-rpxc (CVE-2026-24308): Sensitive information from client configurations logged at INFO level, risking credential exposure in production.
Both affect 3.9.0–3.9.4. Upgrade to 3.9.5 or later, which includes fixes and optional config options to further restrict reverse DNS usage.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@solr/10.0.0.wso2v1/pom.xml` around lines 285 - 305, The pom currently depends
on ZooKeeper artifacts org.apache.zookeeper:zookeeper and
org.apache.zookeeper:zookeeper-jute using the property ${version.zookeeper}
which is set to a vulnerable 3.9.4; update that property to 3.9.5 (or later) so
both zookeeper and zookeeper-jute resolve to 3.9.5 to mitigate CVE-2026-24281
and CVE-2026-24308, then run a build to verify dependency resolution and any
needed compatibility changes for curator-framework/curator-client references to
${curator.version}.
| <!-- JSON Path --> | ||
| <dependency> | ||
| <groupId>com.jayway.jsonpath</groupId> | ||
| <artifactId>json-path</artifactId> | ||
| <version>${json.path.version}</version> | ||
| </dependency> |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
json-path 2.9.0 json-smart vulnerability fix
💡 Result:
JsonPath 2.9.0 uses json-smart 2.5.0, which is vulnerable to CVE-2024-57699 (DoS via stack exhaustion from deeply nested JSON, an incomplete fix for CVE-2023-1370). This affects JsonPath 2.9.0 as confirmed by GitHub issues #1031 and #1033, Snyk, and Maven Repository. The fix is in JsonPath 2.10.0 (released Oct 31, 2025), which upgrades to json-smart 2.6.0 (post-2.5.2 fix). JsonPath 3.0.0 also resolves it. Upgrade to JsonPath 2.10.0 or later. Maven: com.jayway.jsonpath:json-path:2.10.0 or higher.
Citations:
- 1: CVE-2024-57699 on Json-Path:2.9.0 json-path/JsonPath#1031
- 2: Consider updating
net.minidev:json-smartto 2.5.2 to address CVE-2024-57699 json-path/JsonPath#1033 - 3: https://github.com/json-path/JsonPath/releases
- 4: https://central.sonatype.com/artifact/com.jayway.jsonpath/json-path/2.9.0
- 5: Fix CVE-2024-57699 for json-smart json-path/JsonPath#1030
- 6: https://vulert.com/vuln-db/CVE-2024-57699
🏁 Script executed:
# First, find the json.path.version property definition
rg "json\.path\.version" solr/10.0.0.wso2v1/pom.xml -A 1 -B 1Repository: wso2/orbit
Length of output: 280
🏁 Script executed:
# Also check the broader context around line 418 and 763
sed -n '410,430p' solr/10.0.0.wso2v1/pom.xmlRepository: wso2/orbit
Length of output: 696
🏁 Script executed:
# Check around line 763
sed -n '755,770p' solr/10.0.0.wso2v1/pom.xmlRepository: wso2/orbit
Length of output: 777
🌐 Web query:
GHSA-pq2g-wx69-c263 json-smart vulnerability
💡 Result:
GHSA-pq2g-wx69-c263 is a high-severity vulnerability (CVE-2024-57699) in the net.minidev:json-smart Maven package, affecting versions >=2.5.0 and <2.5.2. It involves uncontrolled recursion leading to stack exhaustion and Denial of Service (DoS) when parsing specially crafted JSON input with a large number of '{'. This is due to an incomplete fix for CVE-2023-1370, which only addressed default JSONParser modes like MODE_RFC4627. Patched in version 2.5.2. CVSS v3.1 score: 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H). CWE-674. Published Feb 6, 2025; last updated Mar 12, 2025.
Citations:
- 1: GHSA-pq2g-wx69-c263
- 2: https://osv.dev/GHSA-pq2g-wx69-c263
- 3: https://vulnerability.circl.lu/vuln/GHSA-pq2g-wx69-c263
- 4: https://advisories.gitlab.com/pkg/maven/net.minidev/json-smart/CVE-2024-57699/
🌐 Web query:
CVE-2024-57699 json-smart json-path
💡 Result:
CVE-2024-57699 is a high-severity Denial of Service (DoS) vulnerability in the Netplex json-smart library (Maven package: net.minidev:json-smart), affecting versions 2.5.0 through 2.5.1. It allows remote attackers to trigger stack exhaustion by processing specially crafted JSON input containing a large number of opening curly braces '{'. This stems from an incomplete fix for CVE-2023-1370. CVSS v3.1 score: 7.5 (HIGH) - AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. CWE-674 (Uncontrolled Recursion). The vulnerability impacts projects using json-smart directly or transitively, such as json-path (versions before 2.10.0, which upgraded json-smart to 2.6.0). Fixed in json-smart 2.5.2. For custom JSONParser instances, set the LIMIT_JSON_DEPTH option. PoC available at https://github.com/TurtleLiu/Vul_PoC/tree/main/CVE-2024-57699. Published: February 5, 2025 (NVD). Last modified: February 6, 2025.
Citations:
- 1: https://nvd.nist.gov/vuln/detail/CVE-2024-57699
- 2: GHSA-pq2g-wx69-c263
- 3: https://nvd.nist.gov/nvd.cfm?cvename=CVE-2024-57699
- 4: Fix CVE-2024-57699 for json-smart json-path/JsonPath#1030
- 5: CVE-2024-57699 on Json-Path:2.9.0 json-path/JsonPath#1031
- 6: https://vulert.com/vuln-db/CVE-2024-57699
Upgrade json-path to 2.10.0 or later to resolve CVE-2024-57699 (GHSA-pq2g-wx69-c263) in json-smart 2.5.0.
The transitive dependency net.minidev:json-smart:2.5.0 (pulled in by json-path:2.9.0) is vulnerable to uncontrolled recursion leading to stack exhaustion and DoS via specially crafted JSON payloads with deeply nested objects. json-path 2.10.0+ upgrades json-smart to 2.6.0, which patches this vulnerability. CVSS score: 7.5 (HIGH).
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@solr/10.0.0.wso2v1/pom.xml` around lines 418 - 423, The pom declares the
vulnerable dependency com.jayway.jsonpath:json-path using the property
${json.path.version}; bump this to 2.10.0 or later so its transitive
net.minidev:json-smart is upgraded to 2.6.0. Locate the json-path dependency
(artifactId json-path / groupId com.jayway.jsonpath) and update the
${json.path.version} property (or the explicit <version> element) to "2.10.0" or
a newer safe release, then run a build to verify the updated transitive
json-smart version.
1 participant
Summary by CodeRabbit