[
https://issues.apache.org/jira/browse/SOLR-3613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13411890#comment-13411890
]
Mark Miller commented on SOLR-3613:
-----------------------------------
bq. What do we gain in restricting deployment options, as long as it's simple
enough to keep Solr a clean web-app?
We can do more around out of the box goodness like process management and good
logging and have tools and things that know where to find those. Like a good
normal application. It also lets us stop worrying about how we behave 'as
webapp' and put that energy elsewhere. It also would let us not worry about
testing and supporting all these other containers. They could simply be second
class best effort, and our primary effort gets better. That is basically
matching thinking with reality - as it is, all of our unit tests run in jetty.
Most of the use of Solr is in Jetty. Most of the bugs we find at the container
level are around Jetty. We have had to patch the version of Jetty we are using
to avoid bugs, upgrade Jetty to avoid bugs. If you are not using our shipped
Jetty, your probably not doing it right if you ask me.
bq. This is one of the risks of running TRUNK or ALPHA before a FINAL release.
That is not really how I look at it. 4 was a special case that took place over
years - I care more about the practical effect of the change than I do some
rule about when I should easily screw existing users. Using releases promises
you back compat to some degree - not using them doesn't mean we will change
things wily nilly on you if we can help it. You have to weigh the gains, which
seem minimal at best here IMO.
I'm flexible on what we do for this issue overall, but I've stopped thinking
about Solr as a webapp - like I said, I don't see the gains, and I've seen how
that thought process has held back a good out of the box experience.
> 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
