#7, if I understand Tucu's point correctly, was that removing isDebugEnabled guards also requires updating the logging to use templates rather than string construction. We don't need guards with the new-style templated logging.
+1 besides that though Steve, thanks for writing this up. It seems like the next step would be putting this on the wiki and linking it from places. On Fri, Apr 18, 2014 at 2:32 AM, Steve Loughran <ste...@hortonworks.com>wrote: > OK, should what policy should we recommend, using RFC2119 should/may/must > > Source: > > > 1. switch to SLF4J in imports and use -except in situations where access > to any underlying log4j appender is needed. In that case: retain > commons-logging > 2. Methods that take a commons-logging argument SHOULD add a version > which takes an SLF parameter -where it isn't too expensive to do this > (i.e. code maintenance costs). Maybe these should stop taking logs as > arguments and just use their local logs? > 3. info, warn, and error messages MAY be logged without wrappers > 4. arguments SHOULD be passed as trailing values, so that they can be > on-demand stringified > 5. classes SHOULD provide low-cost toString operators with useful > information. Propose: super.toString() plus, what? values with low cost > eval and no failures if null? > 6. exceptions MUST be added as last value (this gets them picked up by > both the text and the exception trace) > 7. debug messages in production code SHOULD still be protected by an > ifDebugEnabled guard to reduce string construction costs? > > #7 is to address Alejandro's point -I think we could not worry about tests, > because they aren't so important > > Modules > > > 1. existing code MAY switch -ideally via a package-at-a-time basis, in > patches that MUST do nothing but the import and binding. > 2. The same log path (as defined by classname or otherwise) MUST be used > (to ensure that existing log4j settings still work) > 3. existing code MAY have their existing log operations moved to the new > format -in patches that MUST do nothing but update the logging. (I'd > recommend focusing on uses of stringifyException() first) > 4. new classes MUST use SLF4J from the outset -except in tests when > access to underlying log appenders are needed > 5. new modules MUST use SLF4J -except in tests when access to > underlying log appenders are needed > > What I'm trying to do there is have a low-cost migration that doesn't hit > every file at once, and lets people switch to it. > > > > > > On 16 April 2014 21:04, Eric Baldeschwieler <jeri...@gmail.com> wrote: > > > +1 * many. I'd love to see us clean this up. Getting to agreement on > > where we are going would be a huge step forward. > > > > -- > > Eric14 a.k.a. Eric Baldeschwieler > > > > > > On Mon, Apr 14, 2014 at 3:33 PM, Steve Loughran <ste...@hortonworks.com > > >wrote: > > > > > On 11 April 2014 18:37, Alejandro Abdelnur <t...@cloudera.com> wrote: > > > > > > > if you dont convert mgs to templates the dont remove the guards, else > > you > > > > create str mgs obj even when not logging. > > > > > > > > > > > that is -we should have static constants? I like to do that in strings > > > anyway, because tests can stay in sync with messages that change, > though > > > once there's template expansion comparison suddenly gets harder > > > > > > -- > > > CONFIDENTIALITY NOTICE > > > NOTICE: This message is intended for the use of the individual or > entity > > to > > > which it is addressed and may contain information that is confidential, > > > privileged and exempt from disclosure under applicable law. If the > reader > > > of this message is not the intended recipient, you are hereby notified > > that > > > any printing, copying, dissemination, distribution, disclosure or > > > forwarding of this communication is strictly prohibited. If you have > > > received this communication in error, please contact the sender > > immediately > > > and delete it from your system. Thank You. > > > > > > > -- > CONFIDENTIALITY NOTICE > NOTICE: This message is intended for the use of the individual or entity to > which it is addressed and may contain information that is confidential, > privileged and exempt from disclosure under applicable law. If the reader > of this message is not the intended recipient, you are hereby notified that > any printing, copying, dissemination, distribution, disclosure or > forwarding of this communication is strictly prohibited. If you have > received this communication in error, please contact the sender immediately > and delete it from your system. Thank You. >
