axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Veithen <andreas.veit...@gmail.com>
Subject Re: [jira] Commented: (AXIS2-4334) Cannot turn off stdout messages when using WSDL 2.0
Date Sat, 10 Oct 2009 15:27:21 GMT
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.gunathunga@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 <davanum@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
>>> <amilasuriarachchi@gmail.com>  wrote:
>>>>
>>>>
>>>> On Thu, Oct 8, 2009 at 2:50 AM, Andreas
>>>> Veithen<andreas.veithen@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.gunathunga@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)<jira@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/
>

Mime
View raw message