I think it just means they won't officially support deploying war to tomcat or other container. make sense to me if I was in charge of solr, I would just support jetty, predictable with a single configuration. I wouldn't want to spent countless hrs supporting various configurations. Instead use those hrs to further solr development. I'm sure someone that has enough familiarity with tomcat and Java and solr shouldn't have any issue, after all solr is free but you need to pay for support.
On Fri, Oct 7, 2016, 7:13 PM Renee Sun <renee_...@mcafee.com> wrote: > I just read through the following link Shawn shared in his reply: > https://wiki.apache.org/solr/WhyNoWar > > While the following statement is true: > > " Supporting a single set of binary bits is FAR easier than worrying > about what kind of customized environment the user has chosen for their > deployment. " > > But it also probably will reduce the flexibility... for example, we tune > for > Scalability at tomcat level, such as its thread pool etc. I assume the > standalone Solr (which is still using Jetty underlying) would expose > sufficient configurable 'knobs' that allow me to turn 'Solr' to meet our > data work load. > > If we want to minimize the migration work, our existing business logic > component will remain in tomcat, then the fact that we will have co-exist > jetty and tomcat deployed in production system is a bit strange... or is > it? > > Even if I could port our webapps to use Jetty, I assume the way solr is > embedding Jetty I would be able to integrate at that level, I probably end > up with 2 Jetty container instances running on same server, correct? It is > still too early for me to be sure how this will impact our system but I am > a > little worried. > > Renee > > > > -- > View this message in context: > http://lucene.472066.n3.nabble.com/solr-5-leaving-tomcat-will-I-be-the-only-one-fearing-about-this-tp4300065p4300259.html > Sent from the Solr - User mailing list archive at Nabble.com. >
