Hi Andreas, First, appreciate about sharing your insight about logging frameworks. Secondly, to clarify what I mentioned in my last mail, like any other Apache projects Woden-dev also like to listen to our users. At the moment Axis2 is a one of our main user, so it’s important for us to get Axis2’s feedbacks on our modifications.
I think I should update the Woden-dev list again regarding this matter. Thanks, On 10/10/09, Andreas Veithen <[email protected]> wrote: > 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 > > <[email protected]> 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 <[email protected]> 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 > >>> <[email protected]> wrote: > >>>> > >>>> > >>>> On Thu, Oct 8, 2009 at 2:50 AM, Andreas > >>>> Veithen<[email protected]> > >>>> 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 > >>>>> <[email protected]> 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)<[email protected]> > >>>>>> 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/ > > > -- Sagara Gunathunga Blog - http://ssagara.blogspot.com Web - http://people.apache.org/~sagara/
