[ https://issues.apache.org/jira/browse/SOLR-7850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Smiley updated SOLR-7850: ------------------------------- Assignee: David Smiley Fix Version/s: 6.3 > Move user customization out of solr.in.* scripts > ------------------------------------------------ > > Key: SOLR-7850 > URL: https://issues.apache.org/jira/browse/SOLR-7850 > Project: Solr > Issue Type: Improvement > Components: scripts and tools > Affects Versions: 5.2.1 > Reporter: Shawn Heisey > Assignee: David Smiley > Priority: Minor > Fix For: 6.3 > > Attachments: > SOLR_7850_move_bin_solr_in_sh_defaults_into_bin_solr.patch, > SOLR_7850_move_bin_solr_in_sh_defaults_into_bin_solr.patch > > > I've seen a fair number of users customizing solr.in.* scripts to make > changes to their Solr installs. I think the documentation suggests this, > though I haven't confirmed. > One possible problem with this is that we might make changes in those scripts > which such a user would want in their setup, but if they replace the script > with the one in the new version, they will lose their customizations. > I propose instead that we have the startup script look for and utilize a user > customization script, in a similar manner to linux init scripts that look for > /etc/default/packagename, but are able to function without it. I'm not > entirely sure where the script should live or what it should be called. One > idea is server/etc/userconfig.\{sh,cmd\} ... but I haven't put a lot of > thought into it yet. > If the internal behavior of our scripts is largely replaced by a small java > app as detailed in SOLR-7043, then the same thing should apply there -- have > a config file for a user to specify settings, but work perfectly if that > config file is absent. -- 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