Just to make it clear: I don't want to start a discussion about whether the decision to use SLF4J is good or not; it is the choice of the Woden dev community and we will accept whatever they decide. On the other hand, after reading the discussion thread on the woden-dev list, I have to say that I'm very surprised about some of the arguments that have been used to come to the decision to use SLF4J:
1. I think that the discussion started with the wrong question, namely whether to use SLF4J or log4j. The important thing to notice is that SLF4J is an abstract logging API while log4j is a concrete logging implementation. It is clear that a library such as Woden should not impose any particular logging _implementation_ on its users. Therefore the correct question would have been: SLF4J or commons-logging (or java.util.logging). 2. commons-logging was discarded very quickly because it purportedly causes class loading issues. This claim is based on an article from 2002. I also encountered this type of issues with commons-logging, but that was more than five years ago. I didn't have any problems ever since. Axis2 also uses commons-logging and has a complex class loader topology at runtime, but I don't remember seeing any reports about issues with commons-logging. 3. In the discussion, there is no mention about the issues specific to SLF4J. I am currently working in a project that uses several frameworks relying on SLF4J. Here are the things that you should be aware of: - SLF4J needs at least two artifacts to work: the API and (a binding to) a concrete implementation. As pointed out in red in the SLF4J FAQ, artifacts from different versions of SLF4J are incompatible with each other. However, in a Maven project you easily end up with a situation where there is a mismatch between the API version and the implementation version. For somebody familiar with Maven and SLF4J (and class loading if the problem occurs in an EAR project e.g.) this is easy to fix, but many developers don't have all this knowledge. - If there is no other concrete logging implementation, commons-logging will always fall back to java.util.logging. This means that as long as the commons-logging JAR is present, the code will always be executable. This is not the case for SLF4J: it is mandatory to have a concrete binding/implementation, otherwise the code will fail. - In general, frameworks using SLF4J cause a dependency hell: some frameworks only depend on the SLF4J API (which in my opinion is the correct approach), but then you need to add additional SLF4J dependencies to your project; other frameworks also introduce dependencies on a particular binding/implementation, but then you need to exclude these dependencies if the choice doesn't match the choice you have made in your project. - Unpredictable behavior occurs if your project happens to have (transitive) dependencies on several SLF4J bindings/implementations. Catastrophe occurs if your project happens to have a (transitive) dependency on both slf4j-jcl and jcl-over-slf4j. Again, fixing this type of issue requires knowledge in SLF4J, commons-logging and Maven. To summarize: commons-logging in general works out of box and you only need to care about it when setting up a particular logging policy; SLF4J causes much more troubles even before you start thinking about logging. That being said, I like the approach used by SLF4J of statically binding a concrete logging implementation to an abstract API and prefer that over commons-logging's approach of dynamic discovery... Andreas On Thu, Oct 8, 2009 at 14:09, Sagara Gunathunga <sagara.gunathu...@gmail.com> wrote: > Hi Dims, > > This is related to this JIRA issue [1] and also mailing list > discussion [2] . we basically consider about LOG4J or SLF4J as options > Java logging also came-up later but didn't consider about that much. > > If this modification really make a burden to Axis2 project we can > think about to changing the logger in Woden side, It still open for > discussion. > > [1] - http://issues.apache.org/jira/browse/WODEN-71 > [2] - http://www.nabble.com/Best-Logging-Strategy-for-Woden-td25486018.html > > Thanks, > > > On Thu, Oct 8, 2009 at 4:51 PM, Davanum Srinivas <dava...@gmail.com> wrote: >> Just to round up the discussion, did you consider java.util.logging? >> >> thanks, >> dims >> >> On 10/08/2009 04:55 AM, Sagara Gunathunga wrote: >>> >>> On Thu, Oct 8, 2009 at 10:52 AM, Amila Suriarachchi >>> <amilasuriarach...@gmail.com> wrote: >>>> >>>> >>>> On Thu, Oct 8, 2009 at 2:50 AM, Andreas >>>> Veithen<andreas.veit...@gmail.com> >>>> wrote: >>>>> >>>>> For Axis2 it's a bit of an overkill to add SLF4J because of a single >>>>> instruction in a single dependency that is triggered by a single >>>>> feature in Axis2... But OK, if Woden decides to use SLF4J, we don't >>>>> have the choice. >>> >>> Adding SLF4J require at least two new dependencies to Woden dependent >>> projects. yes, sometimes it's an overkill. In other way limiting to >>> one longing implementation is not a good option for an utility >>> project like Woden. We swung with those two thoughts and finally >>> decide to use SLF facade and Log4j as the implementation. >>> >>>>> >>>>> Now we need to decide two things: >>>>> >>>>> - How to integrate SLF4J with our current logging approach? Should we >>>>> use the SLF4J to JCL bridge or the log4j implementation of SLF4J? >>>> >>>> if there is no any special advantage of using SLF4J bridge lets use log4j >>>> implementation since we already shift the log4j with axis2. >>>>> >>>>> - At what level to add the dependency? In axis2-kernel or only in the >>>>> distribution? >>>> >>>> Lets add only to distribution since log4j also added only to >>>> distribution. >>> >>> I have updated Woden 1.0-SNAPSHOTs , Now when you build the Axis2 >>> Maven should able to add SLF4J as a transitive dependency. please try >>> to build and if it fail update the list. >>> >>> Thanks, >>> >>>> >>>> thanks, >>>> Amila. >>>>> >>>>> Any thoughts? >>>>> >>>>> Andreas >>>>> >>>>> On Wed, Oct 7, 2009 at 07:31, Sagara Gunathunga >>>>> <sagara.gunathu...@gmail.com> wrote: >>>>>> >>>>>> Hi Andreas, >>>>>> >>>>>> So far Woden used it's own logging class based on SOP statements. >>>>>> After having a discussion now we moved to SLF4J API because as a >>>>>> utility project it's better to support for a Logging Facade. I think >>>>>> Axis2 need to add SLF4J-API and either commons-binding or >>>>>> log4j-binding as a dependency. >>>>>> >>>>>> Thanks , >>>>>> >>>>>> On Wed, Oct 7, 2009 at 3:24 AM, Andreas Veithen (JIRA)<j...@apache.org> >>>>>> wrote: >>>>>>> >>>>>>> [ >>>>>>> >>>>>>> https://issues.apache.org/jira/browse/AXIS2-4334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12762798#action_12762798 >>>>>>> ] >>>>>>> >>>>>>> Andreas Veithen commented on AXIS2-4334: >>>>>>> ---------------------------------------- >>>>>>> >>>>>>> The change in Woden causes a build failure: >>>>>>> >>>>>>> wsdl20-codegen: >>>>>>> [echo] Running codegen for WSDL 2.0 >>>>>>> [java] Exception in thread "main" java.lang.NoClassDefFoundError: >>>>>>> org/slf4j/LoggerFactory >>>>>>> [java] at >>>>>>> >>>>>>> org.apache.woden.internal.ErrorHandlerImpl.<clinit>(ErrorHandlerImpl.java:37) >>>>>>> [java] at >>>>>>> >>>>>>> org.apache.woden.internal.ErrorReporterImpl.<init>(ErrorReporterImpl.java:130) >>>>>>> [java] at >>>>>>> >>>>>>> org.apache.woden.internal.BaseWSDLFactory.<init>(BaseWSDLFactory.java:39) >>>>>>> [java] at >>>>>>> >>>>>>> org.apache.woden.internal.DOMWSDLFactory.<init>(DOMWSDLFactory.java:30) >>>>>>> [java] at >>>>>>> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) >>>>>>> [java] at >>>>>>> >>>>>>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) >>>>>>> [java] at >>>>>>> >>>>>>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) >>>>>>> [java] at >>>>>>> java.lang.reflect.Constructor.newInstance(Constructor.java:501) >>>>>>> [java] at java.lang.Class.newInstance0(Class.java:350) >>>>>>> [java] at java.lang.Class.newInstance(Class.java:303) >>>>>>> [java] at >>>>>>> org.apache.woden.WSDLFactory.newInstance(WSDLFactory.java:63) >>>>>>> [java] at >>>>>>> org.apache.woden.WSDLFactory.newInstance(WSDLFactory.java:51) >>>>>>> [java] at >>>>>>> >>>>>>> org.apache.axis2.description.WSDL20ToAxisServiceBuilder.readInTheWSDLFile(WSDL20ToAxisServiceBuilder.java:1200) >>>>>>> [java] at >>>>>>> >>>>>>> org.apache.axis2.description.WSDL20ToAxisServiceBuilder.readInTheWSDLFile(WSDL20ToAxisServiceBuilder.java:1176) >>>>>>> [java] at >>>>>>> >>>>>>> org.apache.axis2.description.WSDL20ToAxisServiceBuilder.<init>(WSDL20ToAxisServiceBuilder.java:153) >>>>>>> [java] at >>>>>>> >>>>>>> org.apache.axis2.description.WSDL20ToAllAxisServicesBuilder.<init>(WSDL20ToAllAxisServicesBuilder.java:53) >>>>>>> [java] at >>>>>>> >>>>>>> org.apache.axis2.wsdl.codegen.CodeGenerationEngine.<init>(CodeGenerationEngine.java:102) >>>>>>> [java] at >>>>>>> org.apache.axis2.wsdl.WSDL2Code.main(WSDL2Code.java:35) >>>>>>> [java] at >>>>>>> org.apache.axis2.wsdl.WSDL2Java.main(WSDL2Java.java:24) >>>>>>> [java] Java Result: 1 >>>>>>> >>>>>>> Did Woden switch from commons-logging to SLF4J? >>>>>>> >>>>>>>> Cannot turn off stdout messages when using WSDL 2.0 >>>>>>>> --------------------------------------------------- >>>>>>>> >>>>>>>> Key: AXIS2-4334 >>>>>>>> URL: https://issues.apache.org/jira/browse/AXIS2-4334 >>>>>>>> Project: Axis 2.0 (Axis2) >>>>>>>> Issue Type: Bug >>>>>>>> Affects Versions: 1.4.1 >>>>>>>> Reporter: Deyan Popov >>>>>>>> Attachments: patch.txt, simple_doc.wsdl, >>>>>>>> WSDL20Experiment.java >>>>>>>> >>>>>>>> >>>>>>>> Axis2 writes to stdout when using WSDL 2.0 and I cannot find a way to >>>>>>>> turn it off. When some of the namespace URIs inside the WSDL 2.0 >>>>>>>> document >>>>>>>> are not accessible, I see warning messages like: >>>>>>>> Woden[Warning],0:0,Description-1001,The targetNamespace ' >>>>>>>> http://www.example.org/simple_doc/' is not dereferencable. >>>>>>>> These messages seem to come from the Apache Woden library and are not >>>>>>>> written via Log4j. According to the Woden User Guide there is a >>>>>>>> default >>>>>>>> ErrorHandler which writes to stdout and that ErrorHandler can be >>>>>>>> replaced. >>>>>>>> But I don't see how this can be done via the Axis2 API - in >>>>>>>> particular the >>>>>>>> org.apache.axis2.description.WSDL20ToAllAxisServicesBuilder class. >>>>>>> >>>>>>> -- >>>>>>> This message is automatically generated by JIRA. >>>>>>> - >>>>>>> You can reply to this email to add a comment to the issue online. >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Sagara Gunathunga >>>>>> >>>>>> Blog - http://ssagara.blogspot.com >>>>>> Web - http://people.apache.org/~sagara/ >>>>>> >>>> >>>> >>>> >>>> -- >>>> Amila Suriarachchi >>>> WSO2 Inc. >>>> blog: http://amilachinthaka.blogspot.com/ >>>> >>> >>> >>> >> > > > > -- > Sagara Gunathunga > > Blog - http://ssagara.blogspot.com > Web - http://people.apache.org/~sagara/ >
