[
https://issues.apache.org/jira/browse/SOLR-7160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Woodward updated SOLR-7160:
--------------------------------
Attachment: SOLR-7160.patch
Here's a patch, which does the following:
* renames ConfigSolr to NodeConfig
* makes NodeConfig an immutable POJO, constructed with a Builder
* breaks the actual configuration up a bit, with CloudConfig, LoggingConfig and
UpdateHandlerConfig classes for configuring the relevant bits of functionality.
* The parsing of solr.xml is handled by a SolrXmlConfig class
Once this is in, we can look at passing NodeConfig classes directly to
JettySolrRunner objects, and spawning jetties in parallel.
> Decouple corecontainer configuration classes from solr.xml
> ----------------------------------------------------------
>
> Key: SOLR-7160
> URL: https://issues.apache.org/jira/browse/SOLR-7160
> Project: Solr
> Issue Type: Improvement
> Reporter: Alan Woodward
> Priority: Minor
> Attachments: SOLR-7160.patch
>
>
> The ConfigSolr object that holds configuration options for CoreContainer is
> currently represented as a DOM object, with various methods on it for pulling
> values out of the DOM tree or out of System properties. This has a couple of
> drawbacks:
> 1) it couples the configuration class directly to its representation on disk,
> which is a pain if we ever want to change it (say hello, old-style to
> new-style solr.xml upgrade!).
> 2) the checking of system properties means that it's not threadsafe, which in
> turn means that all our cluster tests have to launch Jettys sequentially,
> rather than in parallel. This results in tests taking about 25 seconds to
> start up, before any of the test logic has been run.
> We should tidy this up.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
