[
https://issues.apache.org/jira/browse/SOLR-6901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14261856#comment-14261856
]
David Smiley commented on SOLR-6901:
------------------------------------
Undeprecate, for the reasons you give.
It may also allow for reduced lines of code when using EmbeddedSolrServer.
There's quite a bit of setup... ESS ought to have a builder or based on all the
possible ways you might want to create it; and creating these are a pain! I
created SOLR-1793 a long time ago with no comments but my comment here
https://issues.apache.org/jira/browse/SOLR-4502?focusedCommentId=14011291 has
more and limited feedback.
> Rethink EmbeddedSolrServer CoreContainer use
> --------------------------------------------
>
> Key: SOLR-6901
> URL: https://issues.apache.org/jira/browse/SOLR-6901
> Project: Solr
> Issue Type: Improvement
> Reporter: Alan Woodward
> Priority: Minor
>
> This was originally going to be about removing the EmbeddedSolrServer
> constructor that takes a SolrCore, which has been deprecated since at least
> 2010 (!). Digging around a bit, though, it seems that having a CoreContainer
> reference in ESS isn't very useful, especially as we only allow querying a
> single core from it.
> What it *does* allow you to do is to send CoreAdminRequests, but again most
> of these are not useful for a single core.
> I don't really have a strong opinion here, other than that we shouldn't carry
> a Deprecated annotation across a third (!) major release.
> * Simplest option is to just nuke that constructor (it's currently used in a
> single test, which can be re-written).
> * Another option would be to 'undeprecate' it, and simply disallow core admin
> requests if coreContainer is null
> * Yet another possibility is to stop holding on to the CoreContainer
> reference, and instead have a custom CoreAdminHandler that only works for
> commands that 'make sense' for a single core (essentially, RELOAD and STATUS)
> and returns the SolrJ equivalent of an UnsupportedOperationException for
> everything else.
> I'm leaning mostly to option 2 at the moment, because I think an embedded
> client that takes a single core is a very useful abstraction (could be a nice
> way of short-circuiting local requests in ShardHandler, for example).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
