This is a spinoff discussion from https://issues.apache.org/jira/browse/SOLR-3613
Solr has so far been a Java web-app which runs in any servlet container, and we have let users decide which one to use. As an example for newbies to quickly get running we've included the lightweight Jetty container in the solr/example folder so people can do "java -jar start.jar". Also our automated tests use Jetty. But in /dist/ there is only the .war and .jars. We have not made any public claims that Jetty is any better than Tomcat or others; to the contrary our web site has had the wording "Solr is written in Java and runs as a standalone full-text search server within a servlet container such as Tomcat" - propably because Tomcat is Apache's own Java server. In the SolrCloud effort introduced in 4.0a, Solr can spin up its own internal ZooKeeper instance for dev/test purposes. It is hardcoded to spin up at port 8983+1000 (Jetty's default), and to change it, Solr sniffs on the System Property "-Djetty.port" and automatically adds 1000 to it for the internal ZK. Note that this is the case not only when running off of the example Jetty server but also when running Solr on an external app server such as Tomcat - you then need to say -Djetty.port=8080 in order to change ZK's port number. Net effect is that from Solr4.0 Solr will be semi-tightly bound to Jetty - "semi" because the bundled ZK is not meant for production and "most" people use Jetty for dev(?) and it IS possible to (mis)use -Djetty.port to move ZK's port for those developing with Tomcat or Resin. This was the background starting the discussion in SOLR-3613. It seems that part of the community wants to change Solr into being a standalone Application requiring Jetty, instead of being an AppServer agnostic web-app. My opinion is that we should stay an agnostic web-app so the downstream consumers and end-users of Solr has a real choice. But at the same time strive to make the built-in Jetty server work as well as possible OOTB (start scripts etc) even to a degree that it is perfectly suitable for production use. Thoughts? -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com Solr Training - www.solrtraining.com --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
