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?
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.
there is a discussion about this on stackoverflow:
you call the shots since you do the work (thanks btw) ;-)
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.