[ 
https://issues.apache.org/jira/browse/SOLR-3613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13411981#comment-13411981
 ] 

Mark Miller commented on SOLR-3613:
-----------------------------------

bq. spinning up a Jetty process alongside their ECM? 

Yeah, that is really what I would recommend. Especially if they are going to 
grow into needing another server later anyway. I think a search server 
(especially one built on java) is simply best run in it's own process. Trying 
to be all things to everyone has it's costs. 

However, as long as we continue to use jetty, it should theoretically be 
possible for anyone to figure things out for another webcontainer - but I'm 
pushing forward changes that apply to what we ship with and add improvements 
around that, and I'm not going to worry about tomcat or resin in that work.

I'm not talking about precluding running as a webapp - I'm talking about owning 
up to the fact that we already are only reliable with jetty - the version that 
we ship. That's the sweetspot config - so I'm going to pimp it out. And I'm 
going to argue against promoting other web containers - cause they won't be 
pimped out and will generally suck as an experience in comparison - this is the 
case now and I plan on trying to make it worse. If a user wants to go that 
route, fine - but it would be bad to promote such an option IMO - for the 
previous myriad of reasons.


                
> 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

Reply via email to