[
https://issues.apache.org/jira/browse/SOLR-3613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13412603#comment-13412603
]
Yonik Seeley commented on SOLR-3613:
------------------------------------
bq. I'm not talking about precluding running as a webapp [...] so I'm going to
pimp [jetty] it out
+1
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.
bq. a thin HTTP layer around Lucene
I've certainly never thought of Solr as that. Solr had faceting, numerics,
etc, years before Lucene. Solr is about being a practical useful search
server... and lately more morphing into a NoSQL server with first-class
full-text search.
> 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]
