Grant Ingersoll wrote:
A bigger question is, should LCF be responsible for this stuff or should Solr,
etc. be responsible for it? For instance, perhaps all Solr needs is to
implement a DataImportHandler processor?
Doesn't Solr also handle document conversions, pipeline, etc.?
Karl
On Mar 3, 2010, at 1:19 PM, Karl Wright wrote:
Erik Hatcher wrote:
I'm curious why the LuceneConnector doesn't use the SolrJ API? Instead,
there's a custom HttpPoster class that does a lot of work that SolrJ already
handles internally.
Also, this probably should be called a SolrConnector instead, eh? Since it's
writing to Solr, not to Lucene directly.
Thanks,
Erik
The two main reasons were as follows. First, it was not clear when initial
research was done exactly what the licensing for SolrJ was. Second, it appears
that Solr itself seemed more configurable than the SolrJ API permitted, as far
as webapp names, paths, etc are concerned. I'm not quite sure why that is, or
whether there's a way to similarly configure SolrJ. If those issues can be
addressed, and if the SolrJ API does not *require* other Apache jars that are
in conflict with those for other connectors (commons-httpclient 4.x, for
instance), then it could likely be changed along the lines you are suggesting.
A naming change is also fine with me.
Karl
