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
---------------------------------------------------------------------

On Fri, Jul 13, 2012 at 5:27 AM, Jan Høydahl <[EMAIL PROTECTED]> 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

---------------------------------------------------------------------

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


---------------------------------------------------------------------

>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:[EMAIL PROTECTED]]
Sent: Friday, July 13, 2012 8:31 AM
To: [EMAIL PROTECTED]
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


---------------------------------------------------------------------
---------------------------------------------------------------------

On Fri, Jul 13, 2012 at 11:37 AM, Dyer, James <[EMAIL PROTECTED]> 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

---------------------------------------------------------------------

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


---------------------------------------------------------------------

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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]]
> Sent: Friday, July 13, 2012 8:31 AM
> To: [EMAIL PROTECTED]
> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> --------------------------------------------------------------

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: [EMAIL PROTECTED]
> -----Original Message-----
> From: Robert Muir [mailto:[EMAIL PROTECTED]]
> Sent: Friday, July 13, 2012 5:48 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [Discuss] Should Solr be an AppServer agnostic WAR or require
> Jetty?
>
> On Fri, Jul 13, 2012 at 11:37 AM, Dyer, James <[EMAIL PROTECTED]>
> 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: [EMAIL PROTECTED] For additional
> commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------

> 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: [EMAIL PROTECTED]
>
>
>> -----Original Message-----
>> From: Robert Muir [mailto:[EMAIL PROTECTED]]
>> Sent: Friday, July 13, 2012 5:48 PM
>> To: [EMAIL PROTECTED]
>> Subject: Re: [Discuss] Should Solr be an AppServer agnostic WAR or require
>> Jetty?
>>
>> On Fri, Jul 13, 2012 at 11:37 AM, Dyer, James <[EMAIL PROTECTED]>
>> 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: [EMAIL PROTECTED] For additional
>> commands, e-mail: [EMAIL PROTECTED]
>
>
> ----------------------------------------------

: > 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

---------------------------------------------------------------------

: > 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

---------------------------------------------------------------------

: > 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

---------------------------------------------------------------------

On Mon, Jul 16, 2012 at 3:46 PM, Chris Hostetter
<[EMAIL PROTECTED]> 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 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

---------------------------------------------------------------------

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


---------------------------------------------------------------------

: > 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

---------------------------------------------------------------------

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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------