Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

  • Upgraded to smartgwt 5.0, still can't get rid of log4j.

    Hello,

    we're trying to get rid of the hard-coded dependency for log4j that you had in smartGWT but according to your release documentation for 5.0 have gotten rid of, enabling us to run with slf4j instead.

    This is what i have done:

    1. added "-DiscUseSlf4j=true" "-DiscUseLog4jConfig=false" to my system startup file (catalina.sh in Tomcat)
    2. Removed log4j.jar from my war lib.

    I get the following error on startup:

    [code]
    SEVERE: Servlet [Init] in web application [/myapp] threw load() exception
    java.lang.VerifyError: (class: com/isomorphic/log/Logger, method: <clinit> signature: ()V) Incompatible argument to function
    at com.isomorphic.base.Init.<clinit>(Init.java:68)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
    [code]

    Have i missed something? Pointers much appreciated.

    EDIT: i tried adding and removing the jar, and it indeed seems that you still require log4j to be on the classpath. I also found your logging page, where you write that you use log4j internally.

    This is very unfortunate for us, because in Hibernate 4, they moved from slf4j to jbosslogging, which will set up logging bridge according to a hard-coded priority which is 1. log4j and 2. slf4j. This basically means that because you need log4j, i cant get proper logging when i upgrade to hibernate 4 (well, there's a system parameter i'll have to try and work out everywhere...).
    Last edited by mathias; 18th May 2015, 12:41.

  • #2
    This error message suggests that you've got two different versions of isomorphic jars on your classpath, which would also explain why log4j still seems to be required.

    Comment


    • #3
      Ok, so you are saying that i *should* be able to not have log4j on the classpath? In that case i'll give it another go :)

      Comment


      • #4
        OK,

        i have now made sure that i'm running only 5.0, nothing else on the classpath, and no log4j in the classpath.

        I start Tomcat with the following command:
        -DiscUseSlf4j=true \
        -DiscUseLog4jConfig=false \


        I cannot deploy, getting the following error:

        Code:
        SEVERE: Servlet [Init] in web application [] threw load() exception
        java.lang.ClassNotFoundException: org.apache.log4j.spi.RootLogger
        	at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1720)
        	at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1571)
        	at com.isomorphic.base.Init.<clinit>(Init.java:68)
        I would like to avoid having log4j on the classpath if possible.

        Comment


        • #5
          I took a look at your "Logger" class. (com.isomorphic.log)

          it still has dependencies on log4j, from what i can see:

          1. It imports a log of log4j-classes:
          Code:
          import org.apache.log4j.LogManager;
          import org.apache.log4j.helpers.Loader;
          import org.apache.log4j.spi.LoggerRepository;
          import org.apache.log4j.spi.RootLogger;
          etc.
          2. it has a Log4j field:
          Code:
          private org.apache.log4j.Logger nativeLog;
          This is in the 5.0 codebase, so i'm not sure if i can see how i could get rid of log4j like you say.

          Comment


          • #6
            To clarify, we've made it possible to configure SmartGWT to send all server logging through sfl4j, but we have not eliminated the JVM dependency on log4j.

            Because we still pervasively use advanced features of log4j when it's available, fully removing the JVM dependency on log4j would require a bunch of code to be moved around and a lot of Java reflection, to little apparent benefit.

            It would be unfortunate if Hibernate 4 really takes log4j's presence on the classpath as an indication you want to use log4j and has no setting to override this. Please do let us know if you find this to be the case. However, even if it is true, this would be something to file as a bug against Hibernate 4.

            Comment


            • #7
              Yes, this is the case.

              You can see a very informative stack overflow, with links to the Hibernate source class here:

              http://stackoverflow.com/questions/11639997/how-do-you-configure-logging-in-hibernate-4-to-use-slf4j

              You can kind of get around it by using a system setting, but its still annoying, and it still will make my tests spew out lots of hibernate logs unless i keep log4j config files around.

              As a personal opinion, i can't see why you would need to have a dependency on log4j, it's basically common practice these days not to hard-code dependency on a specific logging framework, since people have different preferences.

              (It's also a bit unfortunate that you started this thread by implying that you did NOT depend on log4j. It cost me time.)

              Comment


              • #8
                We're tracking an enhancement to fully eliminate even the classpath dependency on log4j, but as we mentioned, this should be an extremely minor issue except for Hibernate's odd behavior here - which still seems like a fairly minor issue if it just requires some command-line flags to work around.

                Comment


                • #9
                  Well, its not minor to me. Good to hear you're looking into it.

                  Comment


                  • #10
                    Hey, just checking if there's been any progress on this issue?

                    Comment


                    • #11
                      "Tracking an enhancement" means this has been placed into a very very long list of possible enhancements (as you can imagine). Basically nothing will happen on this issue until we see at least a few other users who think it matters, because there are many enhancements already on the list that many users have made clear they want.

                      Comment


                      • #12
                        After running into the same problem when i want to use logback, i have found a working solution for me.

                        So here a short how-to guide
                        1) at first i removed log4j from my classpath
                        2) then i bridged log4j to slf4j log4j-over-slf4j
                        3) and at last i write a Dummy RootLogger Class (which is missing in log4j-over-slf4j)

                        Code:
                         
                        package org.apache.log4j.spi;
                        
                        import org.apache.log4j.Level;
                        import org.apache.log4j.Logger;
                        
                        /**
                         * Dummy Class for Smartgwt without Log4j
                         */
                        public class RootLogger extends Logger {
                        
                            public RootLogger(Level level) {
                                super("root");
                            }
                        
                            public final Level getChainedLevel() {
                                return null;
                            }
                        
                            public final void setLevel(Level level) {
                            }
                        }
                        To make the usage simpler I have packed (including the log4j-over-slf4j dependency) this dummy class into a small maven artefact, so all i have to do is add this maven artefact as dependency to my smartgwt project and logging works without any enhancements from Isomorphic.

                        Maybe this can help somebody.

                        Comment


                        • #13
                          As of tomorrow's nightly build of 5.1d, it is no longer necessary for log4j to be present on the classpath at all if you are not using it.

                          Comment


                          • #14
                            Hi Helmut,
                            I am facing the similiar kind of issue what you faced in the past.I replaced the dummy Rootlogger class but still some more classes are missing in the log4j-over-slf4j , is it something i have to put those classes in the log4oversl4j lib?

                            Comment

                            Working...
                            X