I am not sure what you are speaking to here. No logging facade does any better with fronting Log4j 1 than Log4j 2 does. You cannot manipulate the logging configuration through any facade - including SLF4J’s and Commons Logging.
Ralph > On Jun 7, 2016, at 3:55 PM, 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
