[
https://issues.apache.org/jira/browse/SOLR-16241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris M. Hostetter updated SOLR-16241:
--------------------------------------
Attachment: SOLR-16241.patch
Assignee: Chris M. Hostetter
Status: Open (was: Open)
Simple patch that re-orders the member variable declarations & builder "copy
constructor" assignment orders to match the order in the constructor args -- so
it's a little bit easier to read the lists in order and see if/when something
is missing.
If anyone has any suggestions on a test to help future proof against this kind
of mistake down the road, i'm all ears.
> JettyConfig.builder(JettyConfig) misses some properties
> -------------------------------------------------------
>
> Key: SOLR-16241
> URL: https://issues.apache.org/jira/browse/SOLR-16241
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Chris M. Hostetter
> Assignee: Chris M. Hostetter
> Priority: Major
> Attachments: SOLR-16241.patch
>
>
> Since JettyConfig instances are immutable, there is a Builder pattern for
> them, and a static {{JettyConfig.builder(JettyConfig other)}} method to
> create a new Builder from an existing JettyConfig.
> But this method only sets 6 of the 10 properties that available in the
> {{JettyConfig}} constructor (and Builder)
> This can easily bite you when using any code path that depends on
> {{JettyConfig.builder(JettyConfig other)}}
> Notably this impacts any usage of {{MiniSolrCloudCluster}} which _always_
> calls {{JettyConfig.builder(JettyConfig other)}} when starting up jetty nodes
> – so 40% of the options you may try to manipulate on your {{JettyConfig}}
> will be completely ignored once {{MiniSolrCloudCluster}} actually starts the
> jetty nodes
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
