: > I would go down the route and would supply Solr with a : high-performance network layer (like netty) without any Servlet Crap.
personally, i'm -0 on the idea of refactoring Solr to become a complletely staddalone java app instead of a WAR. Being a WAR has historically made it a lot easier for people/companies who are already familar with WARs and have a java servlet container they have an affinity for (because of experience, support contracts, monitoring tools, etc...) to adopt and use Solr with relatively low overhead, and allowed them to easily leverage a lot of features arround solr w/o solr needing to know about it (as Jan menitioned: SSL, client certs, request/listen threads, etc..) But I recognize that the landscape has changed a lot over the years. If there is benefits to be found in abandoning hte WAR model and becoming a standalone process, then we should certianly consider it. But we should definitely be conservative about it, and keep any changes along this line on trunk for a while to smoke testing them out and be sure we havne't missed any important usecases (ie: do a user survey of servlet container features existing users use in conjunction with solr) and that the packaging makes sense. Specificly: it would be a terrible idea to try and rush a change like this in before Solr 4.0-FINAL ... there are already so many big changes since 3.6 that existing users should think about and evaluate when upgrading, we should not introduce a huge hurdle like "Oh, BTW: it's on a WAR anymore so everything you know about deploying solr is wrong" that will hurt 4.0 adoption. Jan really said it dead on... : But as it is now, Solr *is* a web-app and that has its benefits in that : we concentrate on the search features, not the deployment ; and large : organizations already know how to deploy, configure and monitor their : favorite app-server, so Solr is just another use case. One of my -Hoss --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
