8 Replies Latest reply on Jul 27, 2010 10:12 AM by Wujek Srujek

    Un-shaded Weld SE distribution

    Wujek Srujek Newbie

      Hi.
      We are using Weld SE 1.0.1-Final, and also slf4j 1.5.11. The fact that the Weld jar is shaded and has all its dependencies inside, along with slf4j 1.5.10, results in all our tests having the nasty line that our slf4j binding version 1.5.11 is not compatible with slf4j-api 1.5.10. Even though I explicitly have a dep on slf4j-api 1.5.11 it doesn't work, the reason being that when Weld se boots up, slf4j's LoggerFactory version 1.5.10 is in the same jar, and hance it gets loaded, instead of the one that I really want, and fails the 'versionSanityCheck()'. Removing the org.slf4j package from Weld SE jar works, but this is a suboptimal solution as the end users have to mess with the file.
      Similar issue will pop out when for instance a new version of javassist comes out, and someone wants to use it - if Weld SE boots up making the first call to load the classes, the one bundled with Weld SE will be loaded, possibly resulting in wrong behaviour, unless it is updated in Weld SE.


      Is there a jar somewhere that contains only the weld se stuff, without the dependencies included?


      Regards,
      Wujek

        • 1. Re: Un-shaded Weld SE distribution
          Ceki Gulcu Newbie

          The version check code in SLF4J is not very smart. Although 1.5.10 and 1.5.11 are perfectly compatible, since slf4j-api 1.5.10 does not know whether 1.5.11 is compatible, it decides that it is not. You can downgrade your binding to 1.5.10 which should make slf4j-api v1.5.10 happy.  


          By the way, you can safely ignore this particular error message in the case you describe. It's a false alert. slf4j-api will still bind correctly with the underlying implementation. 

          • 2. Re: Un-shaded Weld SE distribution
            Wujek Srujek Newbie

            Hi. I know it works and I can always downgrade (but should a library force me to?). What I am concerned about is that Weld SE prevents me from using the versions of certain libraries that I want, by including them in the jar. Whereas I can see the point in having a jar with all deps included for no-maven projects, I don't see why in a mavenized project we would need to pack everything in one jar and not rely on transitive dependencies - this way I can declare a dep on 1.5.11 or whatever (I am mentioning slf4j, but javassist and other included libraries are subject to this as well) and it will work, and it is way more flexible.


            Best regards,
            Wujek

            • 3. Re: Un-shaded Weld SE distribution
              Peter Royle Newbie

              Probably the best way is to check out the source and build locally. That way you will end up with a original-weld-se-1.0.1-Final.jar file in your target directory:


              svn co http://anonsvn.jboss.org/repos/weld/java-se/tags/1.0.1-Final weld-java-se-1.0.1
              cd weld-java-se-1.0.1/
              mvn install
              ls target/original-weld-se-1.0.1-Final.jar 
              



              I'll see if I can get Pete M to include this jar in the distribution from now on: WELDX-85

              • 4. Re: Un-shaded Weld SE distribution
                Pete Muir Master

                Yes, we should definitely be shipping both the shaded version (for people looking for an easy way to use Weld in Java SE) and the original version, for people who want finer control. I will get the build fixed.

                • 5. Re: Un-shaded Weld SE distribution
                  Wujek Srujek Newbie

                  Any news on this one? It's been 4 months and the unshaded version is still not in the repository, and this hit us again.

                  • 6. Re: Un-shaded Weld SE distribution
                    Robert Kovacevic Newbie

                    Is this solved? Can weld-servlet be replaced by some other set of dependencies? I found weld-servlet-int in the repo, but couldn't get the whole thing working.


                    Weld-servlet is really annoying me with slf4j. As seen here, since slf4j implementation is already bundled, it can't be plugged in:


                    SLF4J: Class path contains multiple SLF4J bindings.
                    SLF4J: Found binding in [jar:file:/C:/Users/robert/.m2/repository/org/jboss/weld/servlet/weld-servlet/1.0.1-Final/weld-servlet-1.0.1-Final.jar!/org/slf4j/impl/StaticLoggerBinder.class]
                    SLF4J: Found binding in [jar:file:/C:/Users/robert/.m2/repository/org/slf4j/slf4j-log4j12/1.5.6/slf4j-log4j12-1.5.6.jar!/org/slf4j/impl/StaticLoggerBinder.class]



                    Manually deleting the weld-servlet/1.0.1-Final/weld-servlet-1.0.1-Final.jar!/org/slf4j/impl solves it.

                    • 7. Re: Un-shaded Weld SE distribution
                      Pete Muir Master

                      For Weld Servlet, you should definitely be able to use the weld-servlet-int as a standalone artifact. Any details about why it wont work?


                      NB Weld SE is different from Weld Servlet.

                      • 8. Re: Un-shaded Weld SE distribution
                        Wujek Srujek Newbie

                        That's nice about Weld-servlet. What about the original question?