Re: [crypto] Logging dependency
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" 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 >To: Commons Developers List >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" 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" wrote: >> >> >On 7 June 2016 at 16:42, Benedikt Ritter wrote: >> >> Hello Gary, >> >> >> >> Gary Gregory 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
Re: [crypto] Logging dependency
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" wrote: >On 7 June 2016 at 16:42, Benedikt Ritter wrote: >> Hello Gary, >> >> Gary Gregory 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
Re: [VOTE] Accept Chimera as new Apache Commons Component
FYI for the Hadoop common-dev@ list, this [VOTE] passed [1]. I don't think the [RESULT] was echoed over here, so I'm just sending this as a quick notice to anyone in the Hadoop community who may have been watching the thread. If you're interested in watching next steps, then please subscribe to dev@commons.apache.org. --Chris Nauroth [1] https://s.apache.org/KRqs On 3/21/16, 1:45 AM, "Benedikt Ritter" wrote: >Hi all, > >after long discussions I think we have gathered enough information to >decide whether we want to accept the Chimera project as a new Apache >Commons component. > >Proposed name: Apache Commons Crypto >Proposal text: >https://github.com/intel-hadoop/chimera/blob/master/PROPOSAL.html >Initial Code Base: https://github.com/intel-hadoop/chimera/ >Initial Committers (Names in alphabetical order): >- Aaron T. Myers (a...@apache.org, Apache Hadoop PMC, one of the original >Crypto dev team in Apache Hadoop) >- Andrew Wang (w...@apache.org, Apache Hadoop PMC, one of the original >Crypto dev team in Apache Hadoop) >- Chris Nauroth (cnaur...@apache.org, Apache Hadoop PMC and active >reviewer) >- Colin P. McCabe (cmcc...@apache.org, Apache Hadoop PMC, one of the >original Crypto dev team in Apache Hadoop) >- Dapeng Sun (s...@apache.org, Apache Sentry Committer, Chimera >contributor) >- Dian Fu (dia...@apache.org, Apache Sqoop Committer, Chimera contributor) >- Dong Chen (do...@apache.org, Apache Hive Committer,interested on >Chimera) >- Ferdinand Xu (x...@apache.org, Apache Hive Committer, Chimera >contributor) >- Haifeng Chen (haifengc...@apache.org, Chimera lead and code contributor) >- Marcelo Vanzin (Apache Spark Committer, Chimera contributor) >- Uma Maheswara Rao G (umamah...@apache.org, Apache Hadoop PMC, One of the >original Crypto dev/review team in Apache Hadoop) >- Yi Liu (y...@apache.org, Apache Hadoop PMC, One of the original Crypto >dev/review team in Apache Hadoop) > >Please review the proposal and vote. >This vote will close no sooner than 72 hours from now, i.e. after 0900 >GMT 24-Mar 2016 > > [ ] +1 Accept Chimera as new Apache Commons Component > [ ] +0 OK, but... > [ ] -0 OK, but really should fix... > [ ] -1 I oppose this because... > >Thank you! >Benedikt - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Accept Chimera as new Apache Commons Component
+1 (non-binding) --Chris Nauroth On 3/21/16, 1:45 AM, "Benedikt Ritter" wrote: >Hi all, > >after long discussions I think we have gathered enough information to >decide whether we want to accept the Chimera project as a new Apache >Commons component. > >Proposed name: Apache Commons Crypto >Proposal text: >https://github.com/intel-hadoop/chimera/blob/master/PROPOSAL.html >Initial Code Base: https://github.com/intel-hadoop/chimera/ >Initial Committers (Names in alphabetical order): >- Aaron T. Myers (a...@apache.org, Apache Hadoop PMC, one of the original >Crypto dev team in Apache Hadoop) >- Andrew Wang (w...@apache.org, Apache Hadoop PMC, one of the original >Crypto dev team in Apache Hadoop) >- Chris Nauroth (cnaur...@apache.org, Apache Hadoop PMC and active >reviewer) >- Colin P. McCabe (cmcc...@apache.org, Apache Hadoop PMC, one of the >original Crypto dev team in Apache Hadoop) >- Dapeng Sun (s...@apache.org, Apache Sentry Committer, Chimera >contributor) >- Dian Fu (dia...@apache.org, Apache Sqoop Committer, Chimera contributor) >- Dong Chen (do...@apache.org, Apache Hive Committer,interested on >Chimera) >- Ferdinand Xu (x...@apache.org, Apache Hive Committer, Chimera >contributor) >- Haifeng Chen (haifengc...@apache.org, Chimera lead and code contributor) >- Marcelo Vanzin (Apache Spark Committer, Chimera contributor) >- Uma Maheswara Rao G (umamah...@apache.org, Apache Hadoop PMC, One of the >original Crypto dev/review team in Apache Hadoop) >- Yi Liu (y...@apache.org, Apache Hadoop PMC, One of the original Crypto >dev/review team in Apache Hadoop) > >Please review the proposal and vote. >This vote will close no sooner than 72 hours from now, i.e. after 0900 >GMT 24-Mar 2016 > > [ ] +1 Accept Chimera as new Apache Commons Component > [ ] +0 OK, but... > [ ] -0 OK, but really should fix... > [ ] -1 I oppose this because... > >Thank you! >Benedikt - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
