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.
