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 <garydgreg...@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" <cnaur...@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" <seb...@gmail.com> wrote: > > >On 7 June 2016 at 16:42, Benedikt Ritter <brit...@apache.org> wrote: > >> Hello Gary, > >> > >> Gary Gregory <garydgreg...@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: garydgreg...@gmail.com | ggreg...@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-unsubscr...@commons.apache.org > >For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
