-1 For all the reasons listed so far... Basically, Solr should focus on search and let whatever container hosting it deal with protocols and communications. Packaging as a war makes deployment really easy (actually wished ZooKeeper could also run in a container) and system admins can easily maintain systems when all its components use the same underlying technology (tomcat in our case).
So unless someone has some example of limitations caused by being packaged as a war, I don't see why. Always seen the Jetty bundled in example as just that, an example to get you up and running fast. For production systems, I have never seen Jetty being used. Steve ________________________________________ From: Shawn Heisey [[email protected]] Sent: May 3, 2013 10:16 AM To: [email protected] Subject: Re: VOTE: solr no longer webapp On 5/2/2013 10:14 PM, Robert Muir wrote: > I think solr should no longer be a war file but a search app. I don't > care how it accomplishes this: jetty, netty, its all up to us. > > Let me know your ideas: I think its a necessary step to move solr forwards. Being fairly new to this, I'm not sure how to express my thoughts on this as a specific vote. I *think* that what I'm after is: -0 I don't have any concrete objections, just questions and some reasons for not changing. If -0 is not the way to express that, let me know. What specific deficiencies are you trying to solve? I don't think we should go with this idea just to eliminate a dependency or be like the competition. This move must also fix a problem that has no other good solution. We already come extremely close to being an executable app by including jetty in the example. Something that I think could possibly be a good compromise, if others think it's OK: Create a build target that builds a standalone application. In 5.0 (or as soon as it's deemed ready), use that for the example. Wait until 5.0 to make it the default build target. If people like it, keep it that way. If they don't, revert in a later minor release. If the nondefault build option starts to see very little use, we can eliminate it in a later major release. Using a container gives us stuff for free that we don't have to write and debug: A tested start/stop mechanism included by the user's choice of container or OS distribution. I chose to use the included jetty and wrote my own init script, but that is outside the skill set of lots of people. This might be one of the reasons you want to make this move - but we'd face the same problem if Solr were executable. Another thing that we get for free, which someone else already mentioned, is authentication. I don't use this, but it's an important thing to have. My init script uses jetty's STOP.PORT mechanism as its first way to stop Solr. It does have a couple of other ways to kill it if that doesn't work. I plan to contribute my (RHEL/CentOS-specific) init script to the project when I have time to clean it up, and I can make some attempts at making versions for other major distributions. Thanks, Shawn --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
