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, "e...@zusammenkunft.net" <e...@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 <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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
