correct. thx
Alejandro (phone typing) > On Apr 22, 2014, at 15:02, Andrew Wang <andrew.w...@cloudera.com> wrote: > > #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. >>
