[
https://issues.apache.org/jira/browse/SOLR-15730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18039913#comment-18039913
]
Jason Gerlowski edited comment on SOLR-15730 at 11/21/25 4:30 PM:
------------------------------------------------------------------
I think shading is the best approach if we think these deps are likely to cause
issues for users. It doesn't solve the CVE-warning problem, but maybe that's
something that Piotr's "vex" work will help with going forward? And it does
solve the "jar version conflict" issue.
bq. If a user isn't using the V2 API with SolrJ (it's experimental / in-flux /
insufficiently tested, after all), can such a user simply exclude the solr-api
JAR, and thus not include Jackson?
Technically, exclusion of jackson would work, with a few caveats:
# There's one v1 place we use jackson currently:
[CoreAdminResponse|https://github.com/apache/solr/blob/main/solr/solrj/src/java/org/apache/solr/client/solrj/response/CoreAdminResponse.java#L32].
We could change this if we really wanted to I guess.
# "v2"-ness is signaled in the class-level Javadocs for request/response
classes and in the "ApiVersion" enum associated with each. But if a user isn't
clicking through to that stuff it'd be hard to tell whether a SolrRequest class
is v2 or not from the name alone. Might be a good idea to indicate v1 vs. v2
in the package name or somewhere else that's more visible.
(Note that the above is about excluding jackson and *not* solr-api. The
solr-api module has constants and other things used throughout solrj; excluding
solr-api itself would be much trickier.)
That said - I'd much prefer "shading" to advertising jackson-exclusion can be
excluded. IMO we should be *expanding* our use of Jackson (for both v1 *and*
v2), not trying to make sure it can be safely excluded.
Jackson absolutely has it's downsides, and it'd be really cool in theory to
have a razor-thin SolrJ. But the cost of that has to be weighed against the
cost of writing and maintaining our own serialization code forever. The math
just doesn't compute on that IMO. And I don't think that's just me: I spent
about an hour and literally couldn't find another database or web-service
client out there that's not using Jackson or a library like it (e.g. "Gson").
[ElasticSearch|https://www.elastic.co/docs/reference/elasticsearch/clients/java/transport#json-mappers]
[OpenSearch|https://github.com/opensearch-project/opensearch-java/blob/main/java-client/build.gradle.kts#L218-L220]
[Spark|https://github.com/apache/spark/blob/master/pom.xml#L1074-L1080]
[Cassandra|https://github.com/apache/cassandra-java-driver/blob/4.x/pom.xml#L72-L73]
[Redis|https://github.com/redis/jedis/blob/master/pom.xml#L60]
[Milvus|https://github.com/milvus-io/milvus-sdk-java/blob/master/pom.xml#L115]
[Vespa|https://github.com/vespa-engine/vespa/blob/master/vespa-feed-client-api/pom.xml#L24-L28]
[Kubernetes|https://github.com/kubernetes-client/java/blob/a2930623bfe982bde822250cd5cb40fe27f42f71/pom.xml#L57]
[AWS Java SDK|https://github.com/aws/aws-sdk-java/blob/master/pom.xml#L429-L430]
[Azure Java
SDK|https://github.com/search?q=repo%3AAzure%2Fazure-sdk-for-java+jackson+path%3Apom.xml&type=code]
etc.
was (Author: gerlowskija):
I think shading is the best approach if we think these deps are likely to cause
issues for users. It doesn't solve the CVE-warning problem, but maybe that's
something that Piotr's "vex" work will help with going forward? And it does
solve the "jar version conflict" issue.
bq. If a user isn't using the V2 API with SolrJ (it's experimental / in-flux /
insufficiently tested, after all), can such a user simply exclude the solr-api
JAR, and thus not include Jackson?
Technically, exclusion of jackson would work, with a few caveats:
# There's one v1 place we use jackson currently:
[CoreAdminResponse|https://github.com/apache/solr/blob/main/solr/solrj/src/java/org/apache/solr/client/solrj/response/CoreAdminResponse.java#L32].
We could change this if we really wanted to I guess.
# "v2"-ness is signaled in the class-level Javadocs for request/response
classes and in the "ApiVersion" enum associated with each. But if a user isn't
clicking through to that stuff it'd be hard to tell whether a SolrRequest class
is v2 or not from the name alone. Might be a good idea to indicate v1 vs. v2
in the package name or somewhere else that's more visible.
(Note that the above is about excluding jackson and *not* solr-api. The
solr-api module has constants and other things used throughout solrj; excluding
solr-api itself would be much trickier.)
That said - I'd much prefer "shading" to advertising jackson-exclusion can be
excluded. IMO we should be *expanding* our use of Jackson (for both v1 *and*
v2), not trying to make sure it can be safely excluded.
Jackson absolutely has it's downsides, and it'd be really cool in theory to
have a razor-thin SolrJ. But the cost of that has to be weighed against the
cost of writing and maintaining our own serialization code forever. The math
just doesn't compute on that IMO. And I don't think that's just me: I spent
about an hour and literally couldn't find another database or web-service
client out there that's not using Jackson or a library like it (e.g. "Gson").
[ElasticSearch|https://www.elastic.co/docs/reference/elasticsearch/clients/java/transport#json-mappers]
[OpenSearch|https://github.com/opensearch-project/opensearch-java/blob/main/java-client/build.gradle.kts#L218-L220]
[Spark|https://github.com/apache/spark/blob/master/pom.xml#L1074-L1080]
[Cassandra|https://github.com/apache/cassandra-java-driver/blob/4.x/pom.xml#L72-L73]
[Redis|https://github.com/redis/jedis/blob/master/pom.xml#L60] and
[Milvus|https://github.com/milvus-io/milvus-sdk-java/blob/master/pom.xml#L115]
[Vespa|https://github.com/vespa-engine/vespa/blob/master/vespa-feed-client-api/pom.xml#L24-L28]
[Kubernetes|https://github.com/kubernetes-client/java/blob/a2930623bfe982bde822250cd5cb40fe27f42f71/pom.xml#L57]
[AWS Java SDK|https://github.com/aws/aws-sdk-java/blob/master/pom.xml#L429-L430]
[Azure Java
SDK|https://github.com/search?q=repo%3AAzure%2Fazure-sdk-for-java+jackson+path%3Apom.xml&type=code]
etc.
> Umbrella: Modularize SolrJ
> --------------------------
>
> Key: SOLR-15730
> URL: https://issues.apache.org/jira/browse/SOLR-15730
> Project: Solr
> Issue Type: Task
> Components: SolrJ
> Reporter: Jan Høydahl
> Priority: Major
> Attachments: Skjermbilde 2021-10-28 kl. 15.38.40.png
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Umbrella issue for breaking up SolrJ into a slim solrj-core with minimal
> dependencies as well as solrj-zk, solrj-streaming, solrj-jdbc etc as needed.
> We can move relevant other JIRAs as sub-tasks to this one to keep everything
> together.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
