lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yonik Seeley (JIRA)" <>
Subject [jira] [Commented] (SOLR-3613) Namespace Solr's JAVA OPTIONS
Date Thu, 12 Jul 2012 08:18:34 GMT


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


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:
>             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
> 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.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:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message