4 Replies Latest reply on Aug 17, 2010 9:04 PM by HuiSheng Xu

    about logging

    HuiSheng Xu Master

      Hi guys,

       

      There are some issues about logging.

       

      https://jira.jboss.org/browse/JBPM-2530 support slf4j

      https://jira.jboss.org/browse/JBPM-1211 complete software logging

      https://jira.jboss.org/browse/JBPM-2422 investigate if should remove abstract layer

       

      I uploaded a patch on https://jira.jboss.org/browse/JBPM-2530, to support slf4j in jBPM-4.4.

       

      But I am not sure about the other two issues,  How could we handle them in the future?  If we have no clear plan for them,  I think we could just closed them as out of date.  If you have any advices please tell me,  Thank you very much.

        • 1. Re: about logging
          Michael Wohlfart Expert

          slf4j is a logging abstraction layer, you can plug in java.util.logging, logback or log4j at deployment time by providing the right jars.

          So JBPM-2422 (removing abstraction layer) seems like a good idea to me otherwise we would have two layers, the one from log4j and the custom implemented from org.jbpm.internal.log, or are there any dependencies that require the org.jbpm.internal.log package?

          • 2. Re: about logging
            HuiSheng Xu Master

            Hi Michael,

             

            My opinion, save the org.jbpm.internal.log package has benefit for the jbpm framework,  whatever the commons-logging or log4j or slf4j changed, we need change too much for the component in jbpm framework.

             

            The only weekness is the logger cannot reflect the real invoking location,  e. g, if we want to print the method or the line of the real logging location, it will always the org.jbpm.internal.log.Log.  But I think this is not a fatal problem.  Event the log4j or slf4j didn't suggest to print method/line number in appender.

             

            So I want to save the abstract layer of jbpm - org.jbpm.internal.log package,  and just close the JBPM-1211 and jBPM-2422.

            • 3. Re: about logging
              Michael Wohlfart Expert

              Hi HuiSheng,

              there is a discussion about this on stackoverflow:

              http://stackoverflow.com/questions/978670/is-it-worth-wrapping-a-logging-framework-in-an-additional-layer

              you call the shots since you do the work (thanks btw) ;-)

              • 4. Re: about logging
                HuiSheng Xu Master

                Hi Michael,

                 

                Thank you for the link.  I want say the reason why I didn't want to remove the log layer of jbpm4 is just don't want to do these switch works.

                 

                There is no doubt that slf4j is perfect abstract layer for framework.  But if we decide to use it to replace our logging layer.  it is means that we should do lots of works on it.

                 

                On the other hand,  many years ago, we just believe log4j is perfect enough,  but now the better layer - slf4j, become more popular.   If sometimes later, there is another better framework appears, should we cost time to switch on it?  Do we really have the requirement to get from slf4j?  By now at least,  I don't think it is neccessary.  So I want to leave log layer as it is right now.

                 

                Thank you for your reply.