[
https://issues.apache.org/jira/browse/SOLR-3613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13413310#comment-13413310
]
Jan Høydahl commented on SOLR-3613:
-----------------------------------
bq. I also don't think we should force "solr." for all the system properties.
If someone ads the ability to optionally check for the webapp prefix, then I
think we should still be free to use zkHost, collection.*, etc, in the
examples/doc.
Why not? It is consistent, short and concise. I was first thinking that the
"solr." prefix is better had as a convention rather than code? But say we do as
you propose and add prefix logic so that given ${myProp:foo}, we'll look for:
# {{solr.myProp}}
# else look for {{myProp}}
In this case we would need to change all literal {{solr.*}} props in all xml
config files. I see two drawbacks with this approach; one is that the examples
then promote the use of short form while we'd like to encourage use of
namespaced form and the other is that if webapp XYZ sets {{myProp}}, and we
have not explicitly set {{solr.myProp}} then Solr will pick up a faulty value
for it. This last could very well happen for generic opts like the ${host:}
currently defined in solr.xml.
So I still think it is better to require a {{solr.}} prefix for all sys props
and leave in the {{solr.}} prefix in config files as today.
Another problematic one from solr.xml is this: hostPort="${jetty.port:}". It
assumes Jetty as Java Application Server, and it feels awkward to say
{{-Djetty.port=8080}} to tell SolrCloud that Tomcat is running on port 8080.
Imagine an ops guy reading the Solr bootstrap script, scratching his head. If
all we do is read the value and add +1000 to pick the port for our internal ZK,
why not be explicit instead and have a {{solr.localZkPort}} prop? (No API to
get the web containers port? In that case we could support relative values and
default to value of "+1000" which would behave as today, but less to specify on
cmdLine).
While in picky mode :-) I'd prefer {{zkRun}} to be {{solr.localZkRun}} to
distinguish that this starts a *local* Zk as opposed to the remote one in
{{zkHost}}. Also, the prop {{zkHost}} is misleading, in that it takes a list of
host:port; perhaps {{solr.zkServers}} is more clear?
{quote}
bq. a thin HTTP layer around Lucene
I've certainly never thought of Solr as that
{quote}
Well, not a pure HTTP layer, but still thin in as in the sense that Lucene does
as much of the core features as possible
> 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: [email protected]
For additional commands, e-mail: [email protected]
