Devil's advocate response:
If you have three other service webapps on that instance of tomcat, then
you face two hurdles:
For the server side, you have to run on another port or find another
place to run Solr - additional hardware, another EC2 instance, etc.
For the client (website) side, you have to reconfigure all copies of
your client code to talk to the new server or new port. If the design
was good, that will just be a config file change and a restart, but for
a lot of people that's going to mean a full recompile and redeployment.
If you choose to let Solr retain the original port, then you face those
same hurdles with the OTHER software running on tomcat. That would not
technically be our problem, but it would be our changes that resulted in
the required work.
If we make a standalone app available as an option now, switch to it as
the default in 5.0, and then remove the .war option in 6.0 or 7.0, most
users will have time to adjust. There will always be those who are
caught unaware no matter how much time we give them.
There are of course potential transition strategies a savvy user could
use - setting up a smart proxy on the original port and forwarding
requests to tomcat and the solr app on new ports, etc.
Thanks,
Shawn
On 5/3/2013 11:14 AM, Robert Muir wrote:
# rm -rf tomcat
# gzip -dc solr.tgz | tar -xvf -
# cd solr/example
# java -jar start.jar
On Fri, May 3, 2013 at 9:52 AM, Steve Molloy <[email protected]
<mailto:[email protected]>> wrote:
So, if ever this passes, what would be the upgrade path for all the
deployments using Solr as a webapp inside tomcat or other container?
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
