10 Replies Latest reply on Oct 2, 2009 12:25 PM by timfox

    Logging dependency

    skaffman

      I suspect this is a rather inflammatory topic, so I'll wade in with caution.

      HornetQ uses java.util.logging (JUL) as its logging API. The reasons are understandable (no dependency on another logging API), but the effects of this decision are hard to live with.

      JUL does not play nice with other logging frameworks. Yes, you can "redirect" JUL logs to the likes of log4j, but the mechanism for doing so is highly invasive, can can only be done at the JVM level. In situations that involve a multi-deployment appserver, this kind of JVM-level configuration is a really bad idea.

      In contrast, using the likes of commons-logging or slf4j makes things immeasurably easier, and works for everyone without fuss.

      Is having external dependencies such a bad thing?

        • 1. Re: Logging dependency
          ataylor

           

          I suspect this is a rather inflammatory topic, so I'll wade in with caution.


          You suspect correctly :)

          Is having external dependencies such a bad thing?


          Well i guess that depends. JBoss 5 now ships with full JUL support so there is no issue using JUL in the App Server.

          Now if you used HornetQ embedded and we used say log4j as our logging framework and your application used sl4j, you would have to ship 2 logging frameworks. Using JUL means the user has the choice of what framework to use, JUL, log4j, slf4j or maybe another logging framework.

          But yes i agree that JUL can be a bit of a pain.

          • 2. Re: Logging dependency
            skaffman

            But JUL was not really designed for this. Bridging from JUL into another framework is hard to do properly in an enterprise environment, because of the way it's configured.

            If a neutral logging API is to be chosen, surely it should be one designed for the purpose of being a neutral framework, and that makes it as easy as possible to bridge into the environment's own infrastructure? That means CL or SLF4J, not JUL or log4j.

            • 3. Re: Logging dependency
              ataylor

              This discussion has been had many a time. In essence if we use slf4j people complain, if we use log4j people complain and the same with JUL, your post is testament to that.

              Its hard to please all the people all of the time :).

              If you feel that strongly about it, you could easily build your own version using what ever framework you want to use, all our logging code is isolated.

              • 4. Re: Logging dependency
                skaffman

                That's what I figured. Oh well, worth a try.

                • 5. Re: Logging dependency
                  ataylor

                  As they say in my neck of the woods, 'shy bairns get no sweets' :)

                  • 6. Re: Logging dependency
                    timfox

                    Actually, I think there is something that can be done here.

                    Right now the indirection works like this.

                    HornetQ code --- > org.hornetq.core.logging.Logger ---> JUL logging ---> log4j appender --> log4j
                    


                    In other words we delegate to JUL to decide which actual appender to use.

                    As skaffman points out this means that configuration has to be at the JDK level which is a pain.

                    Instead we could do this:

                    HornetQ code --- > org.hornetq.core.logging.Logger ---> HornetQ logging plugin --> log4j
                    


                    And we could provide Hornetq logger plugins (this would be a new interface we write) for JUL, log4j etc

                    We would then have a config property at the *HornetQ configuration* level (probably in hornetq-configuration.xml) where the user can choose whether they want JUL, log4j or whatever logging (or they could write their own).

                    With this solution we would still have no dependencies in HornetQ core on any other logging libraries but we would also remove the problem that skaffman points out.


                    • 7. Re: Logging dependency
                      ataylor

                      Sounds good, I'll raise a jira and do it.

                      @skaffman Unless you feel like contributing, it would be a simple task!

                      • 8. Re: Logging dependency
                        skaffman

                        I'd be happy to contribute to this

                        • 9. Re: Logging dependency
                          timfox

                          Excellent :)

                          skaffman - if you fire me an email (tim dot fox at jboss.com) I can point you in the right direction.

                          • 10. Re: Logging dependency
                            timfox

                            Moving this to the dev forum since it's now a dev topic:

                            http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4258455#4258455