lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-3613) Namespace Solr's JAVA OPTIONS
Date Wed, 11 Jul 2012 22:05:35 GMT

    [ 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message