Not so perverse, really. Quite by design that Solr depends on SolrJ. SolrJ
_is_ Solr. EmbeddedSolrServer for example. The distributed and replication
aspects also rely explicitly on SolrJ for communication and more.
I understand Karl's situation here, though I think the only thing I can say is
use the SolrJ appropriate for your Solr version, which means Manifold's hook
may require a separate output connector, one for each version of Solr. I
think, for example, that ManifoldCF would benefit on indexing performance and
leveraging ZK discovery in a SolrCloud environment using the CloudSolrServer
API.
I would imagine, though, that simply using SolrJ in XML-only mode would work
for all the essentials for all of those Solr versions you mentioned using the
Solr 4 version of SolrJ (I've not tried this myself though).
Erik
On Dec 28, 2012, at 09:02 , Jack Krupansky wrote:
> I don't think I've seen any explicit statement, but I have seen at least a
> few user reports of problems caused by using a version of SolrJ that did not
> match the Solr server release. Maybe that related to Javabin versions.
>
> I think it's even worse than that - a lot of the parameter symbol
> definitions, which get enhanced between Solr releases are actually kept in
> the SolrJ portion of the Solr source code. So, perversely, Solr depends on
> SolrJ.
>
> I think I understand what you are trying to do, and maybe most of the time it
> may in fact work, but it may not be guaranteed to work.
>
> -- Jack Krupansky
>
> -----Original Message----- From: [email protected]
> Sent: Friday, December 28, 2012 3:32 AM
> To: [email protected]
> Subject: Is there documentation anywhere describing interoperability of SolrJ?
>
> Hi all,
>
> For the ManifoldCF project, we have an output connector for Solr, and we'd
> like to port it to use SolrJ instead of homegrown code. However, I cannot
> find any mention anywhere of whether anyone has tried to maintain
> compatibility between later versions of SolrJ (e.g. 4.0.0) and previous
> versions of Solr (e.g. 3.x or 1.4). Can someone either point me at the
> document where this is stated, or confirm that there is indeed no such
> supported interoperability?
>
> Thanks,
> Karl
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
