commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Nauroth <cnaur...@hortonworks.com>
Subject Re: [crypto] Logging dependency
Date Tue, 07 Jun 2016 23:09:35 GMT
No, properties vs. XML is not the issue.  The issue is that it seems any
migration from Log4J 1 to Log4J 2 invalidates existing configuration
files.  This is backward-incompatible for system administrators, because
it forces them to translate their logging configuration to a new format
before it will work.

I see now the point about reporting errors via exception rather than
logging.  I think the challenge arises for softer failure modes, where a
call won't completely fail, but logging can reveal more about what
happened internally.  Examples of this are in NativeCodeLoader in
commons-crypto.

--Chris Nauroth




On 6/7/16, 3:55 PM, "ecki@zusammenkunft.net" <ecki@zusammenkunft.net>
wrote:

>Loggin Infrastructure can be quite complex including formatters, filters,
>api- or file based reconfiguration and so on. It can inckude dynamcally
>registering loggers and stuff. Switching the loggin backend is a
>(non-functional) major work in larger products/systems and app servers.
>
>It would be good if dropping a component using a (newer facade) would not
>require this major change. This works for most older log frameworks or
>newer facades (but as it seems not yet for log4j2?).
>
>But I totally agree if a library can communicate most of its error
>conditions in a synchronous exception it is better to integrate than
>components who log verbosely but dont make the errors available to
>callers or listeners (Warnings however might be a different thing)
>
>Gruss
>Bernd
>-- 
>http://bernd.eckenfels.net
>
>-----Original Message-----
>From: Gary Gregory <garydgregory@gmail.com>
>To: Commons Developers List <dev@commons.apache.org>
>Sent: Mi., 08 Juni 2016 0:48
>Subject: Re: [crypto] Logging dependency
>
>Log4j 2 provides minimal support for v1 properties file, and its not
>documented yet beyond the code itself. Log4j 2 does support the Log4j 1
>API
>though, which is the most important level of compatibility.
>
>You make it sound like some folks will not adopt a new library and API
>because of the format in a properties file or XML file? Wow!
>
>Gary
>On Jun 7, 2016 3:41 PM, "Chris Nauroth" <cnauroth@hortonworks.com> wrote:
>
>> Could you please elaborate on the argument for not logging at all?  As a
>> potential user of commons-crypto, I'll be reluctant to use it if it
>> doesn't provide adequate diagnostic logging when something goes wrong.
>>
>> Regarding the choice of Log4J 2, this is also something that could
>>prevent
>> uptake.  For better or worse, I need to support applications that
>> currently use Log4J 1, and therefore they will have an expectation that
>> logging can be tuned through a Log4J 1 log4j.properties or log4j.xml
>>file.
>>  I am not aware of any way for Log4J 2 to provide
>>backwards-compatibility
>> with Log4J 1 configuration files.
>>
>> --Chris Nauroth
>>
>>
>>
>>
>> On 6/7/16, 9:07 AM, "sebb" <sebbaz@gmail.com> wrote:
>>
>> >On 7 June 2016 at 16:42, Benedikt Ritter <britter@apache.org> wrote:
>> >> Hello Gary,
>> >>
>> >> Gary Gregory <garydgregory@gmail.com> schrieb am Di., 7. Juni 2016
um
>> >> 04:01 Uhr:
>> >>
>> >>> Hi All:
>> >>>
>> >>> IMO. if [crypto] is to have a dependency on a logging framework, it
>> >>>should
>> >>> be Log4j 2, not Commons Logging. Log4j 2 has an API module, which
>>you
>> >>>can
>> >>> pair with any number of implementations: Log4j's own Core, JUL,
>>SLF4J,
>> >>>and
>> >>> so on.
>> >>>
>> >>
>> >> I agree, but I'd say a low level component like crypto should not do
>>any
>> >> logging at all.
>> >>
>> >
>> >+1 to not logging
>> >
>> >>>
>> >>> Gary
>> >>>
>> >>> --
>> >>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> >>> Java Persistence with Hibernate, Second Edition
>> >>> <http://www.manning.com/bauer3/>
>> >>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> >>> Spring Batch in Action <http://www.manning.com/templier/>
>> >>> Blog: http://garygregory.wordpress.com
>> >>> Home: http://garygregory.com/
>> >>> Tweet! http://twitter.com/GaryGregory
>> >>>
>> >
>> >---------------------------------------------------------------------
>> >To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >For additional commands, e-mail: dev-help@commons.apache.org
>> >
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>For additional commands, e-mail: dev-help@commons.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message