Whatever we do, we should never, never, never make it more difficult to get Solr running for the first time than what we do now... Hmmm, sounds like I think it's hard to start it the first time. It's not, it's super-easy and we _must not_ lose that. Not saying that anyone proposes making it harder, but let's keep in mind that we get a lot of benefit, IMO, out of someone not having to fiddle with anything at all to test drive Solr starting from scratch.
My $0.02 Erick On Fri, Jul 13, 2012 at 11:37 AM, Dyer, James <james.d...@ingrambook.com> wrote: > From my perspective, working for a company that uses Solr on a bunch of apps, > I really wish we keep it agnostic. I see the case for documenting that "our > testing process exclusively uses Jetty 7, we've included it in our > distribution, and we recommend it". But I don't see why we need to be naming > our parameters "JettyThis" or "JettyThat" and telling people they've got to > use Jetty. The fact is users often need to use other containers. In my > company, we use Jboss 5. That's it. We have a big support contract for it, > our server admins know it, etc. If we were forced to use Jetty, then we > would grudingly use it, but then our cost of ownership just went up a little. > > On the other hand, expecting to test every possible container before you can > tell people its "supported" for a standards-compliant java web-app is just > crazy. This is like saying that DIH's SQLEntityProcessor is only supported > for HSQLDB because that's the one we test against, or that you can't run > Lucene on Solaris because Uwe's Jenkins doesn't have a Solaris environment. > > Perhaps, though there is a middle ground. Beyond telling people what we test > and what recommend, maybe we can write a few tests that check for known bugs > from popular servlet/j2ee containers. Or even a wiki page that says > something like "Some containers have this bug which can hurt in these > instances. To check if your container is stricken with this problem, try > this..." > > But in the end, the advice should be just like what we say when people ask > how big a server they need or what to set their java heap to: test > thoroughly before going to production. > > This is reminding me of one of my pet peeves back when we had Endeca: they > had 3 supported OS-es. That's it. The fact that Solr could run in any > standards-complaint environment was a big plus in my mind. > > James Dyer > E-Commerce Systems > Ingram Content Group > (615) 213-4311 > > > -----Original Message----- > From: Mark Miller [mailto:markrmil...@gmail.com] > Sent: Friday, July 13, 2012 8:31 AM > To: dev@lucene.apache.org > Subject: Re: [Discuss] Should Solr be an AppServer agnostic WAR or require > Jetty? > > > On Jul 13, 2012, at 9:19 AM, Robert Muir wrote: > >> I know the wiki used to >> say the release manager should go and manually test alternative >> containers before releasing: I refuse to do that. Its not the release >> manager's job. > > That's insane anyhow :) The RM can't thorougly test each of other containers > as a 'step' in the release process at the end of the cycle :) Absurd. > > I think that basically meant just smoke test, cause it could not mean much > more. Not sure how much good in the world that bought you, but I agree it's > not the RM's job. > > We know we have a good experience with exactly one version of one web > container - the one we ship. We actually have been pretty public about this > over the past couple years - we have just not changed the website. I can find > a multitude of quotes from various Lucene/Solr committers talking about how > bad an idea it is not to use Jetty due to a variety of issues. You are asking > for a poor experience. > > - Mark Miller > lucidimagination.com > > > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
