Conversation
WalkthroughAdded a new Solr module 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (2)
solr/10.0.0.wso2v1/pom.xml (2)
382-386: Consider using a property for hppc version.Other dependencies use version properties, but hppc has a hardcoded version. For consistency and maintainability, define a property for it.
♻️ Suggested change
Add property:
<hppc.version>0.10.0</hppc.version>Update dependency:
<dependency> <groupId>com.carrotsearch</groupId> <artifactId>hppc</artifactId> - <version>0.10.0</version> + <version>${hppc.version}</version> </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 382 - 386, Add a Maven property for the hppc version and use it in the dependency to match the rest of the project; define a property named hppc.version (value 0.10.0) in the pom properties section and replace the hardcoded <version>0.10.0</version> for the com.carrotsearch:hppc dependency with ${hppc.version} so the dependency uses the new property.
493-496: Consider upgrading maven-shade-plugin version.Version 2.4 is from 2014. Newer versions (3.x) include bug fixes and improved handling of service resource transformations.
♻️ Suggested upgrade
<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-shade-plugin</artifactId> - <version>2.4</version> + <version>3.5.1</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 493 - 496, The POM currently pins the maven-shade-plugin to an old version ("maven-shade-plugin" with <version>2.4</version>); update the plugin declaration to use a modern 3.x release (for example 3.2.4 or latest stable) by changing the <version> value in the maven-shade-plugin plugin block so the project benefits from service resource transformation and bug fixes.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@solr/10.0.0.wso2v1/pom.xml`:
- Around line 382-386: Add a Maven property for the hppc version and use it in
the dependency to match the rest of the project; define a property named
hppc.version (value 0.10.0) in the pom properties section and replace the
hardcoded <version>0.10.0</version> for the com.carrotsearch:hppc dependency
with ${hppc.version} so the dependency uses the new property.
- Around line 493-496: The POM currently pins the maven-shade-plugin to an old
version ("maven-shade-plugin" with <version>2.4</version>); update the plugin
declaration to use a modern 3.x release (for example 3.2.4 or latest stable) by
changing the <version> value in the maven-shade-plugin plugin block so the
project benefits from service resource transformation and bug fixes.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: a295d511-e84f-48c2-b824-3dcec5c397b0
📒 Files selected for processing (2)
pom.xmlsolr/10.0.0.wso2v1/pom.xml
There was a problem hiding this comment.
🧹 Nitpick comments (2)
solr/10.0.0.wso2v1/pom.xml (2)
382-386: Use a property for hppc version.The version is hardcoded here while all other dependencies use properties. Define an
hppc.versionproperty for consistency and easier maintenance.♻️ Suggested fix
Add to properties section:
<hppc.version>0.10.0</hppc.version>Then update the dependency:
<dependency> <groupId>com.carrotsearch</groupId> <artifactId>hppc</artifactId> - <version>0.10.0</version> + <version>${hppc.version}</version> </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 382 - 386, The hppc dependency version is hardcoded; add a new Maven property named hppc.version (value 0.10.0) in the <properties> section and update the <dependency> for com.carrotsearch:hppc to use ${hppc.version} so it matches the other dependency-version properties; locate the <dependency> block with artifactId "hppc" and the project's <properties> to apply the change.
532-532: Remove unused property.The
http.versionproperty is defined but not referenced anywhere in this POM. Consider removing it to avoid confusion.♻️ Suggested fix
- <http.version>[4.3.0,4.4.0)</http.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` at line 532, The POM defines an unused Maven property named http.version which is not referenced anywhere; remove the <http.version> property entry from the POM (delete the xml element defining http.version) so the file no longer contains the unused property and avoids confusion.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@solr/10.0.0.wso2v1/pom.xml`:
- Around line 382-386: The hppc dependency version is hardcoded; add a new Maven
property named hppc.version (value 0.10.0) in the <properties> section and
update the <dependency> for com.carrotsearch:hppc to use ${hppc.version} so it
matches the other dependency-version properties; locate the <dependency> block
with artifactId "hppc" and the project's <properties> to apply the change.
- Line 532: The POM defines an unused Maven property named http.version which is
not referenced anywhere; remove the <http.version> property entry from the POM
(delete the xml element defining http.version) so the file no longer contains
the unused property and avoids confusion.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 6fd69532-c03a-4fe1-b60a-3904e7b61123
📒 Files selected for processing (2)
pom.xmlsolr/10.0.0.wso2v1/pom.xml
🚧 Files skipped from review as they are similar to previous changes (1)
- pom.xml
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 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 455-466: Remove the trailing wildcard optional import from the
Import-Package section by deleting the "*;resolution:=optional" entry and
instead list explicit imports (with versions where appropriate) for any external
packages; if dynamic loading is required use a separate
<DynamicImport-Package>*</DynamicImport-Package> entry rather than a blanket
optional wildcard. Ensure changes are applied to the Import-Package block
(referenced by the Import-Package element) and mirror the explicit versioned
import style used for org.apache.commons.io and org.noggit.
- Around line 234-238: The pom currently pulls org.apache.zookeeper:zookeeper
via the property version.zookeeper set to 3.9.4; update the version.zookeeper
Maven property to "3.9.5" so the dependency block that references
${version.zookeeper} (org.apache.zookeeper:zookeeper) uses ZooKeeper 3.9.5 which
contains fixes for the reported CVEs.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 10e3fd0c-aaaf-4336-8d10-d7be7d20d163
📒 Files selected for processing (1)
solr/10.0.0.wso2v1/pom.xml
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 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 787-788: The Include-Resource entry duplicates the lucene-core
artifact which is already added via Embed-Dependency (inline=false) and
therefore appears both as an embedded JAR on the Bundle-ClassPath and as
unpacked contents; remove the lucene-core entry from the Include-Resource
section so lucene-core remains only as the embedded dependency (leave other
entries like javassist intact) and ensure no other Include-Resource lines
reintroduce lucene-core.
- Line 892: The pom property <jackson.version> should be bumped from 2.18.2 to
2.18.6 (or later) to address GHSA-72hv-8253-57qq; locate the <jackson.version>
property in the POM (currently "2.18.2") and update its value to "2.18.6" (or a
newer 2.18.x release), then rebuild to ensure the updated Jackson artifacts are
pulled into the build.
- Around line 258-262: The POM currently depends on
org.apache.zookeeper:zookeeper but not on the split artifact zookeeper-jute; add
a direct dependency for groupId org.apache.zookeeper, artifactId zookeeper-jute,
version ${version.zookeeper} and then add that coordinate to the
maven-bundle-plugin's Embed-Dependency list (the same place where other
Embed-Dependency entries are declared) so org.apache.jute.* classes are embedded
into the Solr bundle at build time.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: d44de283-a2cb-42e4-8114-d5806f65d8cc
📒 Files selected for processing (1)
solr/10.0.0.wso2v1/pom.xml
| <dependency> | ||
| <groupId>org.apache.zookeeper</groupId> | ||
| <artifactId>zookeeper</artifactId> | ||
| <version>${version.zookeeper}</version> | ||
| </dependency> |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Find and examine the pom.xml file
find . -path "*/solr/10.0.0.wso2v1/pom.xml" -type fRepository: wso2/orbit
Length of output: 82
🏁 Script executed:
# Read the pom.xml file to examine lines around 258-262 and 763-765
wc -l ./solr/10.0.0.wso2v1/pom.xmlRepository: wso2/orbit
Length of output: 86
🏁 Script executed:
# Examine the pom.xml around lines 258-262 and 763-765
echo "=== Lines 250-270 ===" && sed -n '250,270p' ./solr/10.0.0.wso2v1/pom.xml
echo -e "\n=== Lines 755-775 ===" && sed -n '755,775p' ./solr/10.0.0.wso2v1/pom.xmlRepository: wso2/orbit
Length of output: 2148
🏁 Script executed:
# Find the zookeeper version and check if zookeeper-jute is mentioned anywhere
echo "=== Checking zookeeper version ===" && grep -n "version.zookeeper" ./solr/10.0.0.wso2v1/pom.xml
echo -e "\n=== Checking if zookeeper-jute is mentioned ===" && grep -n "zookeeper-jute" ./solr/10.0.0.wso2v1/pom.xmlRepository: wso2/orbit
Length of output: 250
🏁 Script executed:
# Check the entire pom.xml structure around the Embed-Dependency section to understand the full context
sed -n '745,785p' ./solr/10.0.0.wso2v1/pom.xmlRepository: wso2/orbit
Length of output: 2768
🌐 Web query:
ZooKeeper 3.9.4 Maven artifact zookeeper-jute separate dependency
💡 Result:
In ZooKeeper 3.9.4, Jute is published as its own Maven artifact:
<dependency>
<groupId>org.apache.zookeeper</groupId>
<artifactId>zookeeper-jute</artifactId>
<version>3.9.4</version>
</dependency>[1]
If you already depend on org.apache.zookeeper:zookeeper:3.9.4, you typically don’t need to add it manually, because zookeeper declares zookeeper-jute as a compile dependency (so it should come transitively unless you’re excluding it / using dependency management that omits transitives). [2]
Sources
[1] Maven Central (Sonatype) artifact page for org.apache.zookeeper:zookeeper-jute:3.9.4 (central.sonatype.com)
[2] org.apache.zookeeper:zookeeper:3.9.4 dependency list showing zookeeper-jute:3.9.4 (mvnrepository.com)
Citations:
- 1: https://central.sonatype.com/artifact/org.apache.zookeeper/zookeeper-jute/3.9.4
- 2: https://mvnrepository.com/artifact/org.apache.zookeeper/zookeeper/3.9.4/dependencies
🏁 Script executed:
# Check the Felix bundle plugin configuration to see if Embed-Transitive is enabled
echo "=== Looking for Felix bundle plugin configuration ===" && sed -n '700,900p' ./solr/10.0.0.wso2v1/pom.xml | grep -A 50 "maven-bundle-plugin"Repository: wso2/orbit
Length of output: 107
🏁 Script executed:
# Search for maven-bundle-plugin across the entire file
grep -n "maven-bundle-plugin" ./solr/10.0.0.wso2v1/pom.xmlRepository: wso2/orbit
Length of output: 118
🏁 Script executed:
# Examine the maven-bundle-plugin configuration
sed -n '680,800p' ./solr/10.0.0.wso2v1/pom.xmlRepository: wso2/orbit
Length of output: 8395
🏁 Script executed:
# Check if Embed-Transitive is mentioned anywhere
grep -n "Embed-Transitive" ./solr/10.0.0.wso2v1/pom.xmlRepository: wso2/orbit
Length of output: 36
🌐 Web query:
Felix maven-bundle-plugin Embed-Dependency Embed-Transitive transitive dependencies
💡 Result:
<Embed-Dependency>tells the Felix maven-bundle-plugin to embed matched Maven project dependencies into your bundle by generating correspondingInclude-ResourceandBundle-ClassPathentries for bnd. You can match/filter bygroupId,artifactId,version,scope,type,classifier,optional, and you can alsoinline=true. [1]- By default, the plugin only considers direct dependencies for embedding. To also consider the full transitive dependency set, enable:
<Embed-Transitive>true</Embed-Transitive>. Then yourEmbed-Dependencypatterns apply across transitives too. [1] - The bnd documentation for the Felix plugin summarizes this as: it can include Maven transitive dependencies in the JAR and put them on the
Bundle-ClassPath. [2]
Example (embed all compile+runtime deps and their transitives):
<instructions>
<Embed-Dependency>*;scope=compile|runtime</Embed-Dependency>
<Embed-Transitive>true</Embed-Transitive>
</instructions>Sources: [1] Apache Felix maven-bundle-plugin docs (Embedding dependencies / Embed-Transitive) (felix.apache.org), [2] bnd “Apache Felix Maven Bundle Plugin” (Embed-Dependency overview) (bnd.bndtools.org)
Citations:
- 1: https://felix.apache.org/documentation/subprojects/apache-felix-maven-bundle-plugin-bnd.html
- 2: https://bnd.bndtools.org/tools/felix-maven.html
🌐 Web query:
ZooKeeper 3.9.4 zookeeper-jute org.apache.jute at runtime
💡 Result:
In ZooKeeper 3.9.4, the Jute classes (org.apache.jute.*) are shipped in the separate artifact org.apache.zookeeper:zookeeper-jute (“ZooKeeper jute”), and org.apache.zookeeper:zookeeper:3.9.4 declares it as a compile dependency. If you get ClassNotFoundException: org.apache.jute... at runtime, it means zookeeper-jute isn’t on your runtime classpath (often due to provided/compileOnly, an exclusion, or packaging/shading not pulling transitive deps). [1][2]
Fix (ensure it’s present at runtime)
Maven
<dependency>
<groupId>org.apache.zookeeper</groupId>
<artifactId>zookeeper-jute</artifactId>
<version>3.9.4</version>
</dependency>(Or include org.apache.zookeeper:zookeeper:3.9.4 without marking it provided, and don’t exclude zookeeper-jute.) [1][2]
Gradle
implementation("org.apache.zookeeper:zookeeper-jute:3.9.4")(or implementation("org.apache.zookeeper:zookeeper:3.9.4") and make sure transitive deps are packaged). [1][2]
If you tell me your build tool (Maven/Gradle/SBT) and the exact runtime error + how you run/package (fat jar, Spring Boot, app server, etc.), I can point to the specific place it’s getting dropped.
Add zookeeper-jute as a direct dependency and include it in the Embed-Dependency list.
Since ZooKeeper 3.9.4 publishes zookeeper-jute as a separate Maven artifact and Felix's maven-bundle-plugin only embeds direct dependencies (unless Embed-Transitive is enabled, which it is not here), the Solr bundle will not embed org.apache.jute.* classes. This creates a runtime dependency on another bundle to provide these classes.
Suggested fix
<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>
...
caffeine;scope=compile|runtime;inline=false,
zookeeper;scope=compile|runtime;inline=false,
+ zookeeper-jute;scope=compile|runtime;inline=false,
metrics-core;scope=compile|runtime;inline=false,🤖 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 258 - 262, The POM currently depends
on org.apache.zookeeper:zookeeper but not on the split artifact zookeeper-jute;
add a direct dependency for groupId org.apache.zookeeper, artifactId
zookeeper-jute, version ${version.zookeeper} and then add that coordinate to the
maven-bundle-plugin's Embed-Dependency list (the same place where other
Embed-Dependency entries are declared) so org.apache.jute.* classes are embedded
into the Solr bundle at build time.
| lucene-core;scope=compile|runtime;inline=false, | ||
| javassist;scope=compile|runtime;inline=false, |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, let's examine the pom.xml file structure around the mentioned lines
head -n 850 solr/10.0.0.wso2v1/pom.xml | tail -n 100Repository: wso2/orbit
Length of output: 6750
🏁 Script executed:
# Get a broader view of the Embed-Dependency and Include-Resource sections
sed -n '750,850p' solr/10.0.0.wso2v1/pom.xmlRepository: wso2/orbit
Length of output: 6833
🏁 Script executed:
# Check the full context of lines around 787-788 and 823-826
sed -n '770,830p' solr/10.0.0.wso2v1/pom.xml | cat -nRepository: wso2/orbit
Length of output: 4887
Remove duplicate lucene-core from Include-Resource.
lucene-core is already embedded via Embed-Dependency with inline=false (line 787-788), which includes it as a bundled JAR on the Bundle-ClassPath. The Include-Resource directive at line 823-826 then extracts and unpacks the same artifact inline, resulting in the content being present twice in the final bundle: once as the embedded JAR and again as unpacked contents.
Suggested fix
Remove the lucene-core entry from Include-Resource:
<Include-Resource>
`@solr-core-`${version.solr}.jar!/*,
- `@lucene-core-`${version.lucene}.jar!/*,
</Include-Resource>🤖 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 787 - 788, The Include-Resource
entry duplicates the lucene-core artifact which is already added via
Embed-Dependency (inline=false) and therefore appears both as an embedded JAR on
the Bundle-ClassPath and as unpacked contents; remove the lucene-core entry from
the Include-Resource section so lucene-core remains only as the embedded
dependency (leave other entries like javassist intact) and ensure no other
Include-Resource lines reintroduce lucene-core.
| <guava.version>33.4.0-jre</guava.version> | ||
|
|
||
| <!-- NEW: Jackson --> | ||
| <jackson.version>2.18.2</jackson.version> |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
find . -name "pom.xml" -type f | head -20Repository: wso2/orbit
Length of output: 750
🏁 Script executed:
rg "jackson\.version" -A 1 -B 1Repository: wso2/orbit
Length of output: 50366
🌐 Web query:
GHSA-72hv-8253-57qq jackson-core vulnerability async-parser DoS
💡 Result:
GHSA-72hv-8253-57qq (jackson-core) — async-parser DoS
- Issue: Jackson Core’s non-blocking / async JSON parser can bypass
StreamReadConstraints.maxNumberLength(default 1000 chars). An attacker can send JSON containing extremely long numeric tokens, causing excessive memory allocation and CPU work → Denial of Service (DoS). The synchronous parser enforces the limit correctly. [1][2] - Affected:
com.fasterxml.jackson.core:jackson-core>= 2.0.0 and < 2.18.6, plus >= 2.19.0 and < 2.21.1, and >= 3.0.0 and < 3.1.0. [1][2] - Fixed versions: 2.18.6, 2.21.1, 3.1.0. [1][2]
- Mitigation: Upgrade to a fixed version. If you don’t use the async/non-blocking parser API, you’re typically not exposed to this specific constraint-bypass path. [1][2]
Sources: [1] GitLab Advisory Database, GHSA-72hv-8253-57qq. [2] OSV entry for GHSA-72hv-8253-57qq.
🏁 Script executed:
cat -n solr/10.0.0.wso2v1/pom.xml | sed -n '890,895p'Repository: wso2/orbit
Length of output: 273
Update jackson.version to 2.18.6 or later.
GHSA-72hv-8253-57qq is a DoS vulnerability in Jackson Core's async JSON parser that can bypass StreamReadConstraints.maxNumberLength, allowing extremely long numeric tokens to cause excessive memory allocation. All versions before 2.18.6 in the 2.18.x line are affected. Since this property drives the bundled Jackson artifacts, this must be updated to 2.18.6 before release.
Suggested fix
- <jackson.version>2.18.2</jackson.version>
+ <jackson.version>2.18.6</jackson.version>📝 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.
| <jackson.version>2.18.2</jackson.version> | |
| <jackson.version>2.18.6</jackson.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` at line 892, The pom property <jackson.version>
should be bumped from 2.18.2 to 2.18.6 (or later) to address
GHSA-72hv-8253-57qq; locate the <jackson.version> property in the POM (currently
"2.18.2") and update its value to "2.18.6" (or a newer 2.18.x release), then
rebuild to ensure the updated Jackson artifacts are pulled into the build.
1 participant
Purpose
The purpose of this PR is to introduce an OSGi-compliant bundle for Apache Solr 10.0.0 into the WSO2 Orbit repository. This allows WSO2 Identity server to leverage Jetty 12 within the Carbon OSGi runtime.
Summary by CodeRabbit
New Features
Chores