9 Replies Latest reply on Jul 2, 2009 6:01 PM by Francisco Jose Peredo Noguez

    Logging Problem (Log4J)

    Alexander Bell Newbie

      Hi,


      I'm using WebBeans (1.0.0.SNAPSHOT) together with Tomcat 6.0.
      I've put a log4j.properties in my WEB-INF/classes directory.
      Unfortunately the log output doesn't change (level and format of the output) and I suppose that my log4j.properties is not recognized properly (it works in other webapplications without webbeans).
      I've got the webbeans-logging.jar in my classpath.


      How can I set the logging level from INFO to DEBUG?


      Alex



        • 1. Re: Logging Problem (Log4J)
          Pete Muir Master

          You shouldn't need to add webbeans-logging.jar to your classpath, it's included as part of webbeans-servlet.jar.


          Web Beans isn't doing anything to adjust log4j configuration, but it would be worth checking that you are indeed using log4j - by default Tomcat will use JUL.

          • 2. Re: Logging Problem (Log4J)
            Pete Muir Master

            And so Web Beans will use JUL - so try adding log4j.jar to WEB-INF/lib.

            • 3. Re: Logging Problem (Log4J)
              Alexander Bell Newbie

              Hi,


              I've included SLF4J. The JUL and JCL logging output were redirected to SLF4J and SLF4J uses Log4J for logging. After that I saw the DEBUG logging output.


              thanks, Alex

              • 4. Re: Logging Problem (Log4J)
                Francisco Jose Peredo Noguez Master

                I hope one of the extensions on Seam 3.0 is an easy way to invoke the SFL4J bridge so that anyone that wishes to do so (and bet that pretty much everybody) can avoid using JUL. (IMO JUL is the worst piece of c... every included in the JDK)

                • 5. Re: Logging Problem (Log4J)
                  Francisco Jose Peredo Noguez Master

                  In fact... I wonder... why don't use SFL4J directy? any one crazy enough to like JUL will be able to do it using the slf4j-jdk14-*.jar, that would have the extra advantage that you would avoid the pain of using JUL inside the WebBeans RI.

                  • 6. Re: Logging Problem (Log4J)
                    Pete Muir Master

                    We don't use JUL inside Web Beans, but an adapter layer like slf4j that outputs to log4j if present, otherwise JUL.


                    If you want support for slf4j output, please open a WBRI JIRA and provide a patch for the webbeans-logging module. As for using it directly, not particularly interested given that it adds another dependency, and does something which can be trivially achieved with about 3 classes.

                    • 7. Re: Logging Problem (Log4J)
                      Francisco Jose Peredo Noguez Master

                      Pete Muir wrote on Jun 30, 2009 01:09:


                      We don't use JUL inside Web Beans, but an adapter layer like slf4j that outputs to log4j if present, otherwise JUL.


                      That is the best news I have read ever!



                      If you want support for slf4j output, please open a WBRI JIRA and provide a patch for the webbeans-logging module.


                      There is really no need, because slf4j can trick WBRI and make it believe it is log4j... (it can do that for JUL too, but only by initializing an special bridge because because under the java.* namespace cannot be replaced. But if you guys support log4j that means I do not need to use the special bridge, and I am really happy to read that. )



                      As for using it directly, not particularly interested given that it adds another dependency, and does something which can be trivially achieved with about 3 classes.


                      Maybe so, but if you delegated this job to Sfl4j you wouldn't have to maintain those 3 classes (and you would leave to Slf4j the integration to any logging provider). Also integration with Slf4 would have the advantage of getting parameterized logging (something AFAIK JUL and log4j do not have)

                      • 8. Re: Logging Problem (Log4J)
                        Pete Muir Master

                        Francisco Peredo wrote on Jun 30, 2009 21:18:



                        Pete Muir wrote on Jun 30, 2009 01:09:


                        We don't use JUL inside Web Beans, but an adapter layer like slf4j that outputs to log4j if present, otherwise JUL.


                        That is the best news I have read ever!


                        Right, this is the same as Seam :-)





                        As for using it directly, not particularly interested given that it adds another dependency, and does something which can be trivially achieved with about 3 classes.


                        Maybe so, but if you delegated this job to Sfl4j you wouldn't have to maintain those 3 classes (and you would leave to Slf4j the integration to any logging provider).


                        Well then we are down to the argument about whether it's better to maintain 3 classes, or add a dependency. For a application I would add the dependency, for a framework, I wouldn't.


                        Also integration with Slf4 would have the advantage of getting parameterized logging (something AFAIK JUL and log4j do not have)



                        Yes, our logging classes add support for this idea to.

                        • 9. Re: Logging Problem (Log4J)
                          Francisco Jose Peredo Noguez Master

                          Pete Muir wrote on Jul 01, 2009 00:16:



                          Francisco Peredo wrote on Jun 30, 2009 21:18:



                          Pete Muir wrote on Jun 30, 2009 01:09:


                          We don't use JUL inside Web Beans, but an adapter layer like slf4j that outputs to log4j if present, otherwise JUL.


                          That is the best news I have read ever!


                          Right, this is the same as Seam :-)



                          You guys should convince the guys at Mojarra to do the same, i hate being forced to use the bridge when trying to do logging for JSF ;-).