[
https://issues.apache.org/jira/browse/SOLR-3613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13412055#comment-13412055
]
Hoss Man commented on SOLR-3613:
--------------------------------
This issue got way off topic -- what system property names we look for should
be orthogonal to any discussions about what servlet containers we mention on
the website, or test with, or whether we think we should start moving the
project towards being a standalone server instead of a webapp. Those should be
discussed on the mailing list, or in other jiras
Right now, today, solr is a webapp and we are inconsistent in how we deal with
system property names.
We shouldn't try to predict the future -- if there's one thing i've learned,
it's that we don't know how solr will be used (or what recommendations we might
make) in a year, let alone 5.
* Inconsistency is bad, and can easily lead to confusion.
* We should try to fix as many inconsistencies as possible in 4.0 since it is a
major release and we have more freedom here
* Alienating early adopters is also bad, so we should try to avoid it if
possible
For the system properties that have been introduced named "{{foo}}" It's
trivial to change solr so that it starts looking for "{{solr.foo}}" - it's also
trivially to change the code so that it first looks for "{{solr.foo}}" and if
that's not set it looks for "{{foo}}" as a fallback. That way we can be
consistent, update our documentation so it's clear and consistent for new users
that solr's system properties are always named "{{solr.*}}", and still not
screw over early adopters or people who find old blog posts about SolrCloud and
try the old "{{foo}}" commands.
In the unlikely event that someone comes along and says "i see that solr is
looking for a '{{bar}}' system property, but i have usecase XYZ where system
property '{{bar}}' is also used for PDQ and that's breaking solr" we can tell
them "where did you see that solr uses '{{bar}}' ? ... that document is out of
date, you can set '{{solr.bar}}' and solr will happily ignore '{{bar}}' that
you can use for anything you want"
> Namespace Solr's JAVA OPTIONS
> -----------------------------
>
> Key: SOLR-3613
> URL: https://issues.apache.org/jira/browse/SOLR-3613
> Project: Solr
> Issue Type: Improvement
> Affects Versions: 4.0-ALPHA
> Reporter: Jan Høydahl
> Fix For: 4.0
>
>
> Solr being a web-app, should play nicely in a setting where users deploy it
> on a shared appServer.
> To this regard Solr's JAVA_OPTS should be properly name spaced, both to avoid
> name clashes and for clarity when reading your appserver startup script. We
> currently do that with most: {{solr.solr.home, solr.data.dir,
> solr.abortOnConfigurationError, solr.directoryFactory,
> solr.clustering.enabled, solr.velocity.enabled etc}}, but for some opts we
> fail to do so.
> Before release of 4.0 we should make sure to clean this up.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
