Solr
  1. Solr
  2. SOLR-2487

Do not include slf4j-jdk14 jar in WAR

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.2, 4.0-ALPHA
    • Fix Version/s: 3.6, 4.0-ALPHA
    • Component/s: Build
    • Labels:

      Description

      I know we've intentionally bundled slf4j-jdk14-1.5.5.jar in the war to help newbies get up and running. But I find myself re-packaging the war for every customer when adapting to their choice of logger framework, which is counter-productive.

      It would be sufficient to have the jdk-logging binding in example/lib to let the example and tutorial still work OOTB but as soon as you deploy solr.war to production you're forced to explicitly decide what logging to use.

      1. SOLR-2487.patch
        3 kB
        Jan Høydahl
      2. SOLR-2487.patch
        3 kB
        Jan Høydahl
      3. SOLR-2487.patch
        2 kB
        Jan Høydahl

        Issue Links

          Activity

          Jan Høydahl created issue -
          Hide
          David Smiley added a comment -

          I like it Jan! JDK14 logging sucks, any way.

          Show
          David Smiley added a comment - I like it Jan! JDK14 logging sucks, any way.
          Hide
          Hoss Man added a comment -

          It would be sufficient to have the jdk-logging binding in example/lib to let the example and tutorial still work OOTB but as soon as you deploy solr.war to production you're forced to explicitly decide what logging to use.

          Personally, that sounds like a terrible idea to me.

          Novice users would try the demo, see that it works, then try deploying to some other servlet container and suddenly get errors unless the servlet container had already explicitly loaded some slf4j binding jar?

          we already have plenty of users who get confused about how (and even why) they configure the solr home dir when deploying solr to a servlet container – this would make it ever harder for beginners.

          simple things should be simple – novice users should be able to copy a jar, and copy configs, and be good to go.

          for a user who cares about jdk14 logging vs log4j vs whatever, the task of customizing the war is simple and straightforward to understand – but for a solr user who doesn't know anything about java, picking an slf4j binding and configuring their servlet container to load could easily appear like a daunting burden that will make them turn away from even using solr past the tutorial stage.

          this really seems like a no brainer to me

          Show
          Hoss Man added a comment - It would be sufficient to have the jdk-logging binding in example/lib to let the example and tutorial still work OOTB but as soon as you deploy solr.war to production you're forced to explicitly decide what logging to use. Personally, that sounds like a terrible idea to me. Novice users would try the demo, see that it works, then try deploying to some other servlet container and suddenly get errors unless the servlet container had already explicitly loaded some slf4j binding jar? we already have plenty of users who get confused about how (and even why ) they configure the solr home dir when deploying solr to a servlet container – this would make it ever harder for beginners. simple things should be simple – novice users should be able to copy a jar, and copy configs, and be good to go. for a user who cares about jdk14 logging vs log4j vs whatever, the task of customizing the war is simple and straightforward to understand – but for a solr user who doesn't know anything about java, picking an slf4j binding and configuring their servlet container to load could easily appear like a daunting burden that will make them turn away from even using solr past the tutorial stage. this really seems like a no brainer to me
          Hide
          Jan Høydahl added a comment -

          @Hoss
          Your concerns are easily solved by documentation.

          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.

          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.

          From version 1.6 SLF4j will default to NOP binding if no binding is found, so users will still be able to use Solr: http://www.slf4j.org/codes.html#StaticLoggerBinder

          Show
          Jan Høydahl added a comment - @Hoss Your concerns are easily solved by documentation. 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. 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. From version 1.6 SLF4j will default to NOP binding if no binding is found, so users will still be able to use Solr: http://www.slf4j.org/codes.html#StaticLoggerBinder
          Hide
          Uwe Schindler added a comment -

          +1 +1 +1 +1 ...

          Show
          Uwe Schindler added a comment - +1 +1 +1 +1 ...
          Hide
          Hoss Man added a comment -

          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)

          Show
          Hoss Man added a comment - 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)
          Hide
          Jan Høydahl added a comment -

          Poll results from solr-user:

          [3]  I always use the JDK logging as bundled in solr.war, that's perfect
          [6]  I sometimes use log4j or another framework and am happy with re-packaging solr.war
          [5]  Give me solr.war WITHOUT an slf4j logger binding, so I can choose at deploy time
          [4]  Let me choose whether to bundle a binding or not at build time, using an ANT option
          [1]  What's wrong with the "solr/example" Jetty? I never run Solr elsewhere!
          [ ]  What? Solr can do logging? How cool!
          
          [1]  Please, better logging documentation!
          
          Show
          Jan Høydahl added a comment - Poll results from solr-user: [3] I always use the JDK logging as bundled in solr.war, that's perfect [6] I sometimes use log4j or another framework and am happy with re-packaging solr.war [5] Give me solr.war WITHOUT an slf4j logger binding, so I can choose at deploy time [4] Let me choose whether to bundle a binding or not at build time, using an ANT option [1] What's wrong with the "solr/example" Jetty? I never run Solr elsewhere! [ ] What? Solr can do logging? How cool! [1] Please, better logging documentation!
          Hide
          Jan Høydahl added a comment - - edited

          @Hoss, I like your option #1 with an ant option; no need to increase the size of the distro.

          That would also solve the need for those that want no binding or another binding.

          Alternatively we could also include a script in the binary distro which creates a war without a binding.

          Show
          Jan Høydahl added a comment - - edited @Hoss, I like your option #1 with an ant option; no need to increase the size of the distro. That would also solve the need for those that want no binding or another binding. Alternatively we could also include a script in the binary distro which creates a war without a binding.
          Hide
          Jan Høydahl added a comment -

          Objections to choosing to parameterize the build like Hoss suggests?

          Show
          Jan Høydahl added a comment - Objections to choosing to parameterize the build like Hoss suggests?
          Hide
          Robert Muir added a comment -

          Without knowing anything about logging, I just want to say its a bit scary
          to parameterize the build in any way:

          • how are the different possibilities going to be tested?
          • are all possibilities supported, or is only the default/tested parameter the one we officially support?
          Show
          Robert Muir added a comment - Without knowing anything about logging, I just want to say its a bit scary to parameterize the build in any way: how are the different possibilities going to be tested? are all possibilities supported, or is only the default/tested parameter the one we officially support?
          Hide
          Hoss Man added a comment -

          "supported" is always a vague term, but like with every other ant property in our build file, the default is the "supported" one that we test, and if you override a property when building from source that's a customization and we won't promise that it will always work.

          it's no different then if they override the "javac.source" property, or "build.encoding", etc...

          Show
          Hoss Man added a comment - "supported" is always a vague term, but like with every other ant property in our build file, the default is the "supported" one that we test, and if you override a property when building from source that's a customization and we won't promise that it will always work. it's no different then if they override the "javac.source" property, or "build.encoding", etc...
          Hide
          Robert Muir added a comment -

          Hoss, ok, I just was trying to figure out the expectations for testing.

          Testing with a different classpath or whatever is more difficult than the other 'non-default' or 'conditional default' parameters that we randomize in Lucene to solve this issue (e.g. codecs, directories, locales, mergepolicies, ...), thats why I mentioned it.

          Show
          Robert Muir added a comment - Hoss, ok, I just was trying to figure out the expectations for testing. Testing with a different classpath or whatever is more difficult than the other 'non-default' or 'conditional default' parameters that we randomize in Lucene to solve this issue (e.g. codecs, directories, locales, mergepolicies, ...), thats why I mentioned it.
          Hide
          Greg Pendlebury added a comment -

          It would be great to have a skinny WAR available as a Maven artifact. At the moment there is no way in Maven to have it exclude the jdk14 JAR short of rebuilding and rehosting the WAR elsewhere. eg: http://www.jarvana.com/jarvana/browse/org/dspace/dependencies/solr/dspace-solr-webapp/1.4.1.0/

          And to my knowledge at the moment, there is nothing like this available for v3.3.0

          With a skinny WAR in Maven listing all the currently bundled dependencies the end result for most users would be identical, since Maven will go get them all for you anyway. Then people that don't want jdk14 can add this to their own project and they will get everything but that single dependency:
          <dependency>
          <groupId>org.slf4j</groupId>
          <artifactId>slf4j-jdk</artifactId>
          <version>1.6.1</version>
          <scope>provided</scope>
          </dependency>

          Show
          Greg Pendlebury added a comment - It would be great to have a skinny WAR available as a Maven artifact. At the moment there is no way in Maven to have it exclude the jdk14 JAR short of rebuilding and rehosting the WAR elsewhere. eg: http://www.jarvana.com/jarvana/browse/org/dspace/dependencies/solr/dspace-solr-webapp/1.4.1.0/ And to my knowledge at the moment, there is nothing like this available for v3.3.0 With a skinny WAR in Maven listing all the currently bundled dependencies the end result for most users would be identical, since Maven will go get them all for you anyway. Then people that don't want jdk14 can add this to their own project and they will get everything but that single dependency: <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-jdk</artifactId> <version>1.6.1</version> <scope>provided</scope> </dependency>
          Hide
          Greg Pendlebury added a comment - - edited

          "At the moment there is no way in Maven to have it exclude the jdk14 JAR"... Hmm, I shouldn't have stated an absolute like that. I eventually got a script building today that dropped the WAR as a dependency, unpacked it to a '/solr' context folder, then nuked the jdk14 JAR only, leaving the rest in place.

          I'd still prefer a skinny WAR, since it would be a much cleaner build script, and allow me to eliminate duplicate/conflicting JARs on the classpath with greater ease. It would also be more in line with the spirit of how Maven is intended to work... but I have a workaround, and don't expect the world to conform to my wishes

          Show
          Greg Pendlebury added a comment - - edited "At the moment there is no way in Maven to have it exclude the jdk14 JAR"... Hmm, I shouldn't have stated an absolute like that. I eventually got a script building today that dropped the WAR as a dependency, unpacked it to a '/solr' context folder, then nuked the jdk14 JAR only, leaving the rest in place. I'd still prefer a skinny WAR, since it would be a much cleaner build script, and allow me to eliminate duplicate/conflicting JARs on the classpath with greater ease. It would also be more in line with the spirit of how Maven is intended to work... but I have a workaround, and don't expect the world to conform to my wishes
          Hide
          Jan Høydahl added a comment -

          This patch attempts a solution which hopefully solves all needs. It adds a new ant target "dist-war-minimal" which creates a minimal Solr WAR Distribution file, without slf4j jars, except for the slf4j-api itself.

          The target is not included in the "dist" task, so the minimal war will not be packaged redundantly. However, being an explicit target it is more easily understood and discoverable than a build parameter. Users packaging the war using this target must supply the relevant slf4j jars elsewhere on their classpath.

          This minimal war could be a candidate for uploading to maven.

          Show
          Jan Høydahl added a comment - This patch attempts a solution which hopefully solves all needs. It adds a new ant target "dist-war-minimal" which creates a minimal Solr WAR Distribution file, without slf4j jars, except for the slf4j-api itself. The target is not included in the "dist" task, so the minimal war will not be packaged redundantly. However, being an explicit target it is more easily understood and discoverable than a build parameter. Users packaging the war using this target must supply the relevant slf4j jars elsewhere on their classpath. This minimal war could be a candidate for uploading to maven.
          Jan Høydahl made changes -
          Field Original Value New Value
          Attachment SOLR-2487.patch [ 12498464 ]
          Hide
          Hoss Man added a comment -

          Jan: looks fine to me

          I'm not a huge fan of the name "dist-war-minimal" since it's only excluding log related jars (a truly minimal war might eliminate all jars and let you add the ones you need to the classpath) but functionally it seems fine. (maybe "dist-war-no-slf4j")

          Even with the explicit ant target, it still seems like making the properties overridable at runtime would be helpful for people who care about this sort of war customization/minimalization ... it looks like the patch would let you do this if you run "cd solr/webapp && ant dist -Dsolr.war.suffix=-micro -Dexclude.from.war=*.jar" but not if you just run "cd solr/ && ant dist -Dsolr.war.suffix=-micro -Dexclude.from.war=*.jar"

          ... but i dunno, maybe it doesn't matter. In any situation where i would consider customizing the war in any of the ways we're talking about in this issue i would do it in my own build.xml anyway, so maybe it's not worth the extra complexity to the solr build.xml (i would argue that about the entire issue – but i get that slf4j is a particular pain point for some people)

          Show
          Hoss Man added a comment - Jan: looks fine to me I'm not a huge fan of the name "dist-war-minimal" since it's only excluding log related jars (a truly minimal war might eliminate all jars and let you add the ones you need to the classpath) but functionally it seems fine. (maybe "dist-war-no-slf4j") Even with the explicit ant target, it still seems like making the properties overridable at runtime would be helpful for people who care about this sort of war customization/minimalization ... it looks like the patch would let you do this if you run "cd solr/webapp && ant dist -Dsolr.war.suffix=-micro -Dexclude.from.war=*.jar" but not if you just run "cd solr/ && ant dist -Dsolr.war.suffix=-micro -Dexclude.from.war=*.jar" ... but i dunno, maybe it doesn't matter. In any situation where i would consider customizing the war in any of the ways we're talking about in this issue i would do it in my own build.xml anyway, so maybe it's not worth the extra complexity to the solr build.xml (i would argue that about the entire issue – but i get that slf4j is a particular pain point for some people)
          Hide
          Jan Høydahl added a comment -

          Yep, something like dist-war-no-logging would be fine.
          And perhaps a build property "include.in.war" so people can package log4j if they wish by -Dinclude.in.war=log4j-1.2.16.jar,jcl-over-slf4j.jar

          Feel free to give it a shot, I'll likely not get back to this issue before after Barcelona

          Show
          Jan Høydahl added a comment - Yep, something like dist-war-no-logging would be fine. And perhaps a build property "include.in.war" so people can package log4j if they wish by -Dinclude.in.war=log4j-1.2.16.jar,jcl-over-slf4j.jar Feel free to give it a shot, I'll likely not get back to this issue before after Barcelona
          Hide
          David Smiley added a comment -

          How about simply adding an expanded WAR deployment option and then the user can customize the libs or web.xml as they please? I always prefer an expanded WAR because I'm always going to customize it.

          Show
          David Smiley added a comment - How about simply adding an expanded WAR deployment option and then the user can customize the libs or web.xml as they please? I always prefer an expanded WAR because I'm always going to customize it.
          Hide
          Hoss Man added a comment -

          David: I don't really understand what you mean by "adding an expanded WAR deployment option" ... nothing in the solr build system handles "deployment" we just generate artifacts, and one of those artifacts is a war - if you want to expand that war (to customize it) it's trivial to run "jar xf solr.war"

          Show
          Hoss Man added a comment - David: I don't really understand what you mean by "adding an expanded WAR deployment option" ... nothing in the solr build system handles "deployment" we just generate artifacts, and one of those artifacts is a war - if you want to expand that war (to customize it) it's trivial to run "jar xf solr.war"
          Hide
          David Smiley added a comment -

          Hoss: right; the user could simply expand the .war themselves and then customize. I think most webapp deployments would want some sort of customization, the most common of which is logging but there are others. Perhaps a different build.xml option might deploy an expanded WAR to the example jetty webapps dir--just an idea. I admit my first comment on this issue was "I like it Jan!" but there are so many things a user might do to customize the app that I'm not sure if it's worthwhile to add build.xml targets for these things when there is no telling what the user will need to customize. We can just make it easy for them to get going on that customization and the first step is having an exploded deployment so they need not expand a war file. But that's not a big deal.

          Show
          David Smiley added a comment - Hoss: right; the user could simply expand the .war themselves and then customize. I think most webapp deployments would want some sort of customization, the most common of which is logging but there are others. Perhaps a different build.xml option might deploy an expanded WAR to the example jetty webapps dir--just an idea. I admit my first comment on this issue was "I like it Jan!" but there are so many things a user might do to customize the app that I'm not sure if it's worthwhile to add build.xml targets for these things when there is no telling what the user will need to customize. We can just make it easy for them to get going on that customization and the first step is having an exploded deployment so they need not expand a war file. But that's not a big deal.
          Hide
          Jan Høydahl added a comment -

          New patch with target name "dist-war-excl-slf4j". Now the exclude.from.war param also works across the whole war.

          I tested the params with the dist target and it also works equivalently:

          ant -Dexclude.from.war=*over-slf4j*,slf4j-jdk14* -Dsolr.war.suffix=--excl-slf4j clean dist
          
          Show
          Jan Høydahl added a comment - New patch with target name "dist-war-excl-slf4j". Now the exclude.from.war param also works across the whole war. I tested the params with the dist target and it also works equivalently: ant -Dexclude.from.war=*over-slf4j*,slf4j-jdk14* -Dsolr.war.suffix=--excl-slf4j clean dist
          Jan Høydahl made changes -
          Attachment SOLR-2487.patch [ 12504879 ]
          Hide
          Hoss Man added a comment -

          Jan: +1

          Show
          Hoss Man added a comment - Jan: +1
          Hide
          Jan Høydahl added a comment -

          Planning to commit this in not too long

          Show
          Jan Høydahl added a comment - Planning to commit this in not too long
          Jan Høydahl made changes -
          Assignee Jan Høydahl [ janhoy ]
          Fix Version/s 3.6 [ 12319065 ]
          Fix Version/s 4.0 [ 12314992 ]
          Hide
          Jan Høydahl added a comment -

          Same patch with CHANGES.txt entry

          Show
          Jan Høydahl added a comment - Same patch with CHANGES.txt entry
          Jan Høydahl made changes -
          Attachment SOLR-2487.patch [ 12510700 ]
          Jan Høydahl committed 1231982 (3 files)
          Reviews: none

          SOLR-2487: Do not include slf4j-jdk14 jar in WAR

          Hide
          Jan Høydahl added a comment -

          Fixed in 3.x and trunk

          Show
          Jan Høydahl added a comment - Fixed in 3.x and trunk
          Jan Høydahl made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Hide
          Neil Hooey added a comment -

          Can someone upload the excl-slf4j war to Maven as Jan Høydahl mentioned?

          Show
          Neil Hooey added a comment - Can someone upload the excl-slf4j war to Maven as Jan Høydahl mentioned?
          Neil Hooey made changes -
          Link This issue blocks SOLR-3431 [ SOLR-3431 ]
          Hide
          Lance Norskog added a comment -

          What if instead the distribution included an ant file for these various changes people want to make?

          • Change the logger
          • Change logger properties
          • Remove esoteric contribs
          • change web.xml file
          Show
          Lance Norskog added a comment - What if instead the distribution included an ant file for these various changes people want to make? Change the logger Change logger properties Remove esoteric contribs change web.xml file
          Hide
          Jan Høydahl added a comment -

          Neil, I don't think we as a project will upload multiple war's to Maven. You'll have to build your own using ant dist-war-excl-slf4j. Perhaps if you have a local repo such as Artifactory you can put a copy there, or upload it to some other repo that you can access.

          Show
          Jan Høydahl added a comment - Neil, I don't think we as a project will upload multiple war's to Maven. You'll have to build your own using ant dist-war-excl-slf4j. Perhaps if you have a local repo such as Artifactory you can put a copy there, or upload it to some other repo that you can access.
          Hide
          Neil Hooey added a comment -

          If you're using Maven to build a Solr project, you can add these lines to the <plugins> section to eliminate slf4j bindings that come from Solr dependencies:

          <plugin>
            <artifactId>maven-war-plugin</artifactId>
            <version>2.2</version>
            <configuration>
              <packagingExcludes>WEB-INF/lib/slf4j-jdk14-1.6.4.jar</packagingExcludes>
            </configuration>
          </plugin>
          

          If you have the setting <packaging>war</packaging>, Maven will strip the slf4j jar from the built war in target/ and should clear the way for your logback or other loggers to function properly.

          Show
          Neil Hooey added a comment - If you're using Maven to build a Solr project, you can add these lines to the <plugins> section to eliminate slf4j bindings that come from Solr dependencies: <plugin> <artifactId>maven-war-plugin</artifactId> <version>2.2</version> <configuration> <packagingExcludes>WEB-INF/lib/slf4j-jdk14-1.6.4.jar</packagingExcludes> </configuration> </plugin> If you have the setting <packaging>war</packaging> , Maven will strip the slf4j jar from the built war in target/ and should clear the way for your logback or other loggers to function properly.
          Hide
          Greg Pendlebury added a comment -

          @Neil, that's way better then the way I do things now. Thanks.

          Maven continues to surprise me.

          Show
          Greg Pendlebury added a comment - @Neil, that's way better then the way I do things now. Thanks. Maven continues to surprise me.
          Jan Høydahl made changes -
          Link This issue relates to SOLR-3706 [ SOLR-3706 ]
          Hoss Man made changes -
          Link This issue is related to SOLR-3918 [ SOLR-3918 ]
          Gavin made changes -
          Link This issue blocks SOLR-3431 [ SOLR-3431 ]
          Gavin made changes -
          Link This issue is depended upon by SOLR-3431 [ SOLR-3431 ]
          Uwe Schindler made changes -
          Status Resolved [ 5 ] Closed [ 6 ]

            People

            • Assignee:
              Jan Høydahl
              Reporter:
              Jan Høydahl
            • Votes:
              5 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development