[
https://issues.apache.org/jira/browse/SOLR-12142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445866#comment-16445866
]
David Smiley commented on SOLR-12142:
-------------------------------------
So this method, EmbeddedSolrServer.request(...) confusingly looks up the
requestHandler twice – once on the coreContainer reference (I wish there was a
comment explaining why), and failing that then more normally further below at
line 190:
[https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/client/solrj/embedded/EmbeddedSolrServer.java#L190]
You changed the first occurrence but not the second. Again; a test would have
revealed this oversight I think. I'll cook up a patch. Maybe that would even
happen indirectly if the SolrTextTagger were to be incorporated directly into
Solr; a few people have asked me about this.
> EmbeddedSolrServer should use req.getContentWriter
> ---------------------------------------------------
>
> Key: SOLR-12142
> URL: https://issues.apache.org/jira/browse/SOLR-12142
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: David Smiley
> Assignee: Noble Paul
> Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-12142.patch
>
>
> In SOLR-11380, SolrRequest.getContentWriter was introduced as a replacement
> for getContentStreams. However, EmbeddedSolrServer still calls
> getContentStreams, and so clients who need to send POST data to it cannot yet
> switch from the Deprecated API to the new API. The SolrTextTagger is an
> example of a project where one would want to do this.
> It seems EmbeddedSolrServer ought to check for getContentWriter and if
> present then convert it into a ContentStream somehow. For the time being,
> ESS needs to call both since both APIs exist.
> CC [~noble.paul]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
