The novice users you're talking about are not likely to ever move past running Solr from the included Jetty in the example folder (I've seen such people). When you get to deploying to another servlet container, then you already know what a Java servlet container is. You also know about Java logging, setting Java Opts, and most importantly you read the install docs and understand how to copy a jar file into a folder.
just because there are people who never move past "java -jar start.jar" doesn't mean all novice users stick with "java -jar start.jar" forever – Use of solr beyond "java -jar start.jar" does not mean people are experts in java/jars/wars/logging – there is a middle ground between "i know nothing about java" and "i know enough to make a concious choice about an SLF4J implementation" and we shouldn't screw those people over and make their life more difficult.
we routinely get questions from users on the list about how to use solr in tomcat, or jetty (installed standalone), etc.... Either because they are dealing with a hosting provider (or IT department) that runs the servlet container for them, or because they want to use the servlet container installation provided by their OS distribution.
SLF4j is now so common that the issue of having multiple crashing SLF4j bindings in your classpath will be more annoying to novice users than the opposite.
I have seen far more questions on the solr-user list about getting solr up and running in alternate servlet container then i have about dealing with SLF4j bindings.
From version 1.6 SLF4j will default to NOP binding if no binding is found
That, with out a doubt, would be the absolute worst possible situation i can imagine. Under your proposal (in which no SLF4J imple would be provided in the war we ship) new users, with no solr/java experience, who are most in need of good log/debug messages telling them whats going on and what problems they might be having when they deploy solr, would get absolutely no log messages of any kind when deploying solr.war "as is" into a servlet container.
No, fucking, way.
- basic functionality (using solr) should be basic
- advanced functionality (customizing your logging impl) should be advanced
JDK Logging, whatever anyone may think about it from a feature standpoint, is 100% ubiquitious. Every servlet container on the planet must provide some mechanism of dealing with JDK Logging, because the Java Spec requires it. For that reason alone, regardless of how crapy anyone may think it is, it should be the default.
I'm not opposed to making life easier for people who want to use an alternate impl (if re-waring is deemed too muhc of a burden) – but we should not screw over the majority of novice users (who already have a lot of differnet things to learn about) to make life a little easier for advanced users who care about their logging impl and can easily see what to do to change it.
Here are my counter proposals:
1) we parameterize the build, such that there is a "solr.slf4j.impl.path" property (that defaults to "./lib/slf4j-jdk14-1.6.1.jar") which is used by the "dist-war" target when building the war file. People who build from src (and I think it's totally reasonable to assume anyone who cares about the SLF4J impl is likely already building form source, or could start doing so easily) can set that property to whatever impl they want included in the war, or set it to blank to not include anything (so they can have their servlet container load it at the system level)
2) ship two versions of the jar: one as it is today with the slf4j-jdk14-1.6.1.jar in place, and other "solr-minimal.war" that containly only the web.xml, JSPs, html, and images – but no jars or other class files. Advanced users that want total control over the jars used (but don't wnat to roll their own war file) can use this minimial war file in a servlet container where they have explicitly loaded the jars of their choosing (as you're suggesting people do with the slf4j binding of their choice)
I would vote for #1 ... but if people really feel that asking people to build there own war file to customize the slf4j binding jar is a burden on advanced users, then i don't see why SLF4J should be special – we should go with option #2 to let every jar be customizable in this way.
(Option #2 may also be preferable to some distro repackagers (like debian, redhat) that want to be able to have a single copy of every jar on the system (instead of being baked into the war)