[
https://issues.apache.org/jira/browse/SOLR-15730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17833987#comment-17833987
]
Jason Gerlowski edited comment on SOLR-15730 at 4/4/24 3:48 PM:
----------------------------------------------------------------
bq. Is it strictly needed for SolrJ runtime
As things stand today the v2 SolrRequest classes we generate are very dependent
on Jackson. So in 9.5.0 at least, the answer is "yes".
Going forward though, nothing is impossible if there's enough community
interest and will. The v2 classes are all experimental after all - I'm sure we
could work out some solution if I'm the only one in favor of Jackson. Maybe
the v2 SolrRequest classes only support 'javabin' unless some other
solrj-jackson library is provided?
But while I think it's possible, I also think it'd be a very bad move for us
strategically. We're a Search community - we shouldn't be doubling down on
proprietary wire formats, or maintaining our own serde when there are OTS
libraries that do this much better than we can (and with much lower
maintenance-cost to boot).
Think of all the NamedList-inspection code that could be removed. All of the
ClassCastException's and JavaBinCodec bugs we've sunk time into over the years.
IMO the cost of maintaining all of this serde and parsing code is astronomical.
bq. Is Jackson picky wrt version compatibility so that users need to sync their
own jackson use with ours, if so should one consider shading it?
This I'm less sure about, but IMO it seems promising. It'd be interesting to
see which Jackson version range SolrJ 9.5.0 can tolerate without issue, but I
couldn't say offhand. FWIW, our use of Jackson is pretty basic in terms of
APIs.
was (Author: gerlowskija):
bq. Is it strictly needed for SolrJ runtime
As things stand today the v2 SolrRequest classes we generate are very dependent
on Jackson. So in 9.5.0 at least, the answer is "yes".
Going forward though, nothing is impossible if there's enough community
interest and will. The v2 classes are all experimental after all - I'm sure we
could work out some solution if I'm the only one in favor of Jackson. Maybe
the v2 SolrRequest classes only support 'javabin' unless some other
solrj-jackson library is provided?
But while I think it's possible, I also think it'd be a very bad move for us
strategically. We're a Search community - we shouldn't be doubling down on
proprietary wire formats, or maintaining our own serde when there are OTS
libraries that do this much better than we can (and with much lower
maintenance-cost to boot).
bq. Is Jackson picky wrt version compatibility so that users need to sync their
own jackson use with ours, if so should one consider shading it?
This I'm less sure about, but IMO it seems promising. It'd be interesting to
see which Jackson version range SolrJ 9.5.0 can tolerate without issue, but I
couldn't say offhand. FWIW, our use of Jackson is pretty basic in terms of
APIs.
> 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: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
