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" <[email protected]> wrote: >On 7 June 2016 at 16:42, Benedikt Ritter <[email protected]> wrote: >> Hello Gary, >> >> Gary Gregory <[email protected]> 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: [email protected] | [email protected] >>> 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: [email protected] >For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
