Re: [Discuss] Should Solr be an AppServer agnostic WAR or require Jetty?
I've created SOLR-3654 as a placeholder for adding tests using Tomcat (and possibly other). -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com Solr Training - www.solrtraining.com On 16. juli 2012, at 23:52, Chris Hostetter wrote: : Specificly: it would be a terrible idea to try and rush a change like this : in before Solr 4.0-FINAL ... : : That's just a silly premise - no one in this conversation even remotely : suggested we stop using webapps or wars for Solr 4.0-FINAL. Switching to : non webapp tech is 'probably' a bit of work. Right ... I didn't get the impression anyone who had spoken up so far was suggestiong a change like this for Solr 4.0-FINAL. I just wanted to state that while i have very little opinion about *if* we should make a change like this, i have strong opinions about *when* we should try to make a change like this, if the discussion does go in that direction. -Hoss - 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
Re: [Discuss] Should Solr be an AppServer agnostic WAR or require Jetty?
: 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.
:
: We are not naming parameters jetty this or jetty that - we are pre
: configuring solr.xml to pick up the jetty port from jetty.port (which is
: a sys prop used when starting jetty). This is so that you do not have to
: pass the port twice by default - a silly limitation. The built in solr
Right. To be very clear, these statements from Jan are not accurate...
* It is hardcoded to spin up at port 8983+1000 (Jetty's default)
* Solr sniffs on the System Property -Djetty.port
* when running Solr on an external app server such as Tomcat - you then need
to say -Djetty.port=8080
...nothing in solr *code* explicitly looks for jetty.port ... the port
info for solrcloud is configured using hostPort in the solr.xml file,
and in the example configs we ship, we have 'hostPort=${jetty.port:}' so
it picks up the host port automaticly from jetty without hte user needing
to explicitly configure it. Likewise the 8983+1000 logic is acutally
hostPort + 1000, and even that is just a default if the zookeeper config
doesn't specify a port. People wanting to use tomcat would
never have to refer to or care about jetty.port anywhere in their
configs or installation -- but they would want to modify the example
configs to fit their installation (as should anyone using solr in
production)
-Hoss
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [Discuss] Should Solr be an AppServer agnostic WAR or require Jetty?
: 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 ... : I don't think its crazy at all. Just like : TimeZone/Codec/Locale/Directory impl, if Solr should be agnostic to : it, then the test framework should rotate between different : implementations and pass. but how far down the rabit hole do you want to go? To use we don't test with it therefor it's not supported as a blanket statement can easily lead to things like you are using JRE 1.7.2-u27 and we only run tests using JVM 1.7.2-u26 and JVM 1.7.2-u27, so at the moment we don't support your specific JVM and don't wnat ot hear your bug reports. Or what about You have made modifications to the example solr config files such that you are using a specific combination of features that does't existing in any of the files we use in automated testing, therefore you are doing something untested, therefore your configs are unsupported. In general the concept of what supported vs unsupported means is vague and missleading. lucene is not a company. people don't have support contracts with us. wether something is or isn't supported is entirely dependent on wether or not someone on the mailing list is interested in replying to your question or putting up a patch for your bug report. Just because we don't have automated tests using tomcat doesn't mean tomcat is unsupported -- there are plenty of people offering assistance with tomcat related questions on solr-user. Likewise: the fact that our tests run in Jetty doens't mean jetty is more supported then any other container, because no one is promising that we will absolutely help you if if you have a jetty related bug. My point being: (as long as solr is a webapp) there is a big difference between saying: 1) Solr is a WAR that should work in any standards compliant servlet container. Example configuration is provided for running in Jetty, which is the servlet container used for all of Solr's automated tests. ...vs... 2) Solr is only supported running in Jetty ...#1 is not only more informative then #2, but also more accurate, because there is no official support for anything, so lets just stop throwing the word supported/unsupported arround at all. -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [Discuss] Should Solr be an AppServer agnostic WAR or require Jetty?
: 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
Re: [Discuss] Should Solr be an AppServer agnostic WAR or require Jetty?
On Mon, Jul 16, 2012 at 3:46 PM, Chris Hostetter hossman_luc...@fucit.org wrote: : 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 ... : I don't think its crazy at all. Just like : TimeZone/Codec/Locale/Directory impl, if Solr should be agnostic to : it, then the test framework should rotate between different : implementations and pass. but how far down the rabit hole do you want to go? To use we don't test with it therefor it's not supported as a blanket statement can easily lead to things like you are using JRE 1.7.2-u27 and we only run tests using JVM 1.7.2-u26 and JVM 1.7.2-u27, so at the moment we don't support your specific JVM and don't wnat ot hear your bug reports. Don't quote me out of context. I said on this thread So if other containers are supported, then more than one must be tested. Then we know from running the tests if things are assuming container = Jetty. Tomcat is open source and this can be done. You dont need to test all of them, you just need to test one thats !Jetty. Why is everyone on this thread so anti-testing. -- lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [Discuss] Should Solr be an AppServer agnostic WAR or require Jetty?
: To use we don't test with it therefor it's not supported as a blanket : statement can easily lead to things like you are using JRE 1.7.2-u27 and : we only run tests using JVM 1.7.2-u26 and JVM 1.7.2-u27, so at the moment : we don't support your specific JVM and don't wnat ot hear your bug : reports. : : Don't quote me out of context. I wasn't trying to quote you out of context, i wasn't trying to quote you specificly at all: i was refering to general attitudes, and philosophies, and hypothetical future statements in quotes. : Why is everyone on this thread so anti-testing. I'm not anti-testing. If someone wants to contribute some automated tests that use tomcat, that would be awesome. I'm anti-using the words supported or unsupported in any way -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [Discuss] Should Solr be an AppServer agnostic WAR or require Jetty?
On Jul 16, 2012, at 3:59 PM, Chris Hostetter wrote: Specificly: it would be a terrible idea to try and rush a change like this in before Solr 4.0-FINAL ... That's just a silly premise - no one in this conversation even remotely suggested we stop using webapps or wars for Solr 4.0-FINAL. Switching to non webapp tech is 'probably' a bit of work. - Mark - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [Discuss] Should Solr be an AppServer agnostic WAR or require Jetty?
: Specificly: it would be a terrible idea to try and rush a change like this : in before Solr 4.0-FINAL ... : : That's just a silly premise - no one in this conversation even remotely : suggested we stop using webapps or wars for Solr 4.0-FINAL. Switching to : non webapp tech is 'probably' a bit of work. Right ... I didn't get the impression anyone who had spoken up so far was suggestiong a change like this for Solr 4.0-FINAL. I just wanted to state that while i have very little opinion about *if* we should make a change like this, i have strong opinions about *when* we should try to make a change like this, if the discussion does go in that direction. -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [Discuss] Should Solr be an AppServer agnostic WAR or require Jetty?
On Fri, Jul 13, 2012 at 5:27 AM, Jan Høydahl jan@cominvent.com wrote: 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. My opinion (said previously many times) is that whatever we decide to support: it *must* be tested. So if other containers are supported, then more than one must be tested. Then we know from running the tests if things are assuming container = Jetty. Otherwise, we only support Jetty in my eyes. 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. -- lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
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
RE: [Discuss] Should Solr be an AppServer agnostic WAR or require Jetty?
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
Re: [Discuss] Should Solr be an AppServer agnostic WAR or require Jetty?
On Fri, Jul 13, 2012 at 11:37 AM, Dyer, James james.d...@ingrambook.com wrote: 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. I don't think its crazy at all. Just like TimeZone/Codec/Locale/Directory impl, if Solr should be agnostic to it, then the test framework should rotate between different implementations and pass. As far as Lucene, we try to do this, sure we didnt have a Windows jenkins until recently, but we at least simulate its crazy filesystem semantics in all tests via MockDirectoryWrapper. Not even trying to do this kinda testing for anything but jetty = not supported. -- lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [Discuss] Should Solr be an AppServer agnostic WAR or require Jetty?
On Jul 13, 2012, at 11:37 AM, Dyer, James wrote: 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. We are not naming parameters jetty this or jetty that - we are pre configuring solr.xml to pick up the jetty port from jetty.port (which is a sys prop used when starting jetty). This is so that you do not have to pass the port twice by default - a silly limitation. The built in solr name is hostPort and it's set and configurable in solr.xml. This change had it's own JIRA issue and discussion some time ago. We are also not telling people they have got to use Jetty. We are telling them they are asking for trouble if they do not. There are a variety of things for distrib and solrcloud that have come up and we have tested and worked around with Jetty. If you want to go use Tomcat, I'd say, have fun :) I wouldn't recommend it. As one of the major contributors to SolrCloud, I'd strongly recommend anyone wishing to use it use Jetty. All of the developers that have been closely in involved with tests and bugs and jetty issues seem to come away recommending you use our released version of Jetty. It would seem silly not to head that advice, but users are free to do what they want. Nothing precludes them from trying to dump things into Tomcat if they are hell bent on it. - Mark Miller lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [Discuss] Should Solr be an AppServer agnostic WAR or require Jetty?
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
RE: [Discuss] Should Solr be an AppServer agnostic WAR or require Jetty?
In addition: Solr is *not* and J2EE application! It just uses the servlet container to have a connection to outside. Installing Solr is JBoss or any other full fledged J2EE container is a waste of resources and controllability. I would go down the route and would supply Solr with a high-performance network layer (like netty) without any Servlet Crap. We don’t use anything from Servlet contains, only some very limited entry points to get the requests from the network mapped to our handlers (RequestHandlers are already half of a HTTP server, because we don’t use any features for mapping Requests to handlers any J2EE container would provide). Solr is a server and not a webapp. Do you install MySQL inside a servlet container? Do you install PostgreSQL inside a servlet Container? Do you install *foobar* inside a Servlet Container if it’s a database-like server? NO! - As so Solr. Solr, like ElasticSearch (which does not use servlets) is a server and you run it from command line or init.d/upstart scripts like any other database server. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Robert Muir [mailto:rcm...@gmail.com] Sent: Friday, July 13, 2012 5:48 PM To: dev@lucene.apache.org Subject: Re: [Discuss] Should Solr be an AppServer agnostic WAR or require Jetty? On Fri, Jul 13, 2012 at 11:37 AM, Dyer, James james.d...@ingrambook.com wrote: 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. I don't think its crazy at all. Just like TimeZone/Codec/Locale/Directory impl, if Solr should be agnostic to it, then the test framework should rotate between different implementations and pass. As far as Lucene, we try to do this, sure we didnt have a Windows jenkins until recently, but we at least simulate its crazy filesystem semantics in all tests via MockDirectoryWrapper. Not even trying to do this kinda testing for anything but jetty = not supported. -- 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
Re: [Discuss] Should Solr be an AppServer agnostic WAR or require Jetty?
I would go down the route and would supply Solr with a high-performance network layer (like netty) without any Servlet Crap. Yea, that would certainly be an interesting path to explore and a more attractive way to morph Solr into a standalone server than being a Jetty-only webapp. It would probably simplify and speed many things up but also open up another box of problems. But I can't help to think it would be cool to be able to ssh into a Solr server and do stuff through a CLI :) 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 customers use Resin for all their webapps, and also run Solr in Resin, reusing their IT dept's best practice deployment and security stuff. They also needed certificate based authentication and encryption on all traffic to the Solr servers since their index contains sensitive docs, so they added HTTPS with certificates easily since they knew the Resin container already. -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com Solr Training - www.solrtraining.com On 13. juli 2012, at 17:56, Uwe Schindler wrote: In addition: Solr is *not* and J2EE application! It just uses the servlet container to have a connection to outside. Installing Solr is JBoss or any other full fledged J2EE container is a waste of resources and controllability. I would go down the route and would supply Solr with a high-performance network layer (like netty) without any Servlet Crap. We don’t use anything from Servlet contains, only some very limited entry points to get the requests from the network mapped to our handlers (RequestHandlers are already half of a HTTP server, because we don’t use any features for mapping Requests to handlers any J2EE container would provide). Solr is a server and not a webapp. Do you install MySQL inside a servlet container? Do you install PostgreSQL inside a servlet Container? Do you install *foobar* inside a Servlet Container if it’s a database-like server? NO! - As so Solr. Solr, like ElasticSearch (which does not use servlets) is a server and you run it from command line or init.d/upstart scripts like any other database server. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Robert Muir [mailto:rcm...@gmail.com] Sent: Friday, July 13, 2012 5:48 PM To: dev@lucene.apache.org Subject: Re: [Discuss] Should Solr be an AppServer agnostic WAR or require Jetty? On Fri, Jul 13, 2012 at 11:37 AM, Dyer, James james.d...@ingrambook.com wrote: 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. I don't think its crazy at all. Just like TimeZone/Codec/Locale/Directory impl, if Solr should be agnostic to it, then the test framework should rotate between different implementations and pass. As far as Lucene, we try to do this, sure we didnt have a Windows jenkins until recently, but we at least simulate its crazy filesystem semantics in all tests via MockDirectoryWrapper. Not even trying to do this kinda testing for anything but jetty = not supported. -- 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
