search

lishunli / projectlombok

Automatically exported from code.google.com/p/projectlombok
0 stars 0 forks source link

Log4j2 Annotation must must support getFormatterLogger method in addition to getLogger method #569

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. this is an enhancement i am asking
2.
3.

What is the expected output? What do you see instead?
What i expect is @Log4j2 is to accept a annotation parameter like 
String creationMethod default "getLogger"

So when user says @Log4j2("getFormatterLogger"); it must return a formatted 
logger instead of normal logger. By Default Logger creationMethod could remain 
in consistence with others (which is getLogger).

Why am i asking this?
I like this project lombok and has been a very great experience so far.
I am asking this as this logger(formatted one) removes the code drudgery 
if(log.isDebugEnabled()) transparently.Also it handles the string construction 
once only when debug level is checked(Pl read the Log4j2 manual for more 
details). It actually comes to your project theme much more than any one else. 
I feel this is a missing piece which you should include.

What version of the product are you using? On what operating system?
12
Windows(Eclipse), Linux 

Please provide any additional information below.

Original issue reported on code.google.com by venkates...@gmail.com on 1 Sep 2013 at 8:00

GoogleCodeExporter commented 9 years ago 
1) If we're going to make this, I propose to extend @Log4j2 to get an extra 
parameter:
  boolean formatted() default false;
2) We're not going to have the name of the method a String
3) I don't see how this removes the "code drudgery if(log.isDebugEnabled()) 
transparently". As far as I can see, it only allows java string formatting 
instead of only used toString for object parameters.
4) We're working at a different approach where lombok will insert if-statements 
automagically for log statements. The only downside is that you are limited to 
a single line to generate your log message.

Original comment by r.spilker on 2 Sep 2013 at 8:10

GoogleCodeExporter commented 9 years ago 
Also, in most cases the toString is just fine, or you can easily replace the 
toString with a single value. It is only logging, so as long as the data is in 
there, it's fine. For all other cases: it's not boilerplate anymore.

Original comment by r.spilker on 2 Sep 2013 at 8:13

GoogleCodeExporter commented 9 years ago 
Hey

I was reading basically; 
a) http://logging.apache.org/log4j/2.x/manual/api.html and 
b) http://logging.apache.org/log4j/2.x/performance.html 
where it conveys a statement that 
"The best approach to avoid the cost of parameter construction is to use Log4j 
2's formatting capabilities. For example, instead of the above write:"
            logger.debug("Entry number: {} is {}", i, entry[i]);

So anyways; as long as i get LogManager.getFormatterLogger() i am good and it 
helps.

Original comment by venkates...@gmail.com on 2 Sep 2013 at 3:10

GoogleCodeExporter commented 9 years ago 
> Also, in most cases the toString is just fine, or you can easily replace the 
toString with a single value. It is only logging, so as long as the data is in 
there, it's fine. For all other cases: it's not boilerplate anymore.

I don't think so: I don't remember having seen anything like `logger.info(o)`, 
it was always something like `logger.info("initial value of o is " + o)`, which 
is rather costly in case of logging disabled.

> 3) I don't see how this removes the "code drudgery if(log.isDebugEnabled()) 
transparently". As far as I can see, it only allows java string formatting 
instead of only used toString for object parameters.

It allows you to leave the if-statement out: 
http://www.slf4j.org/faq.html#logging_performance

> 4) We're working at a different approach where lombok will insert 
if-statements automagically for log statements.

Nice!

Original comment by Maaarti...@gmail.com on 6 Sep 2013 at 12:44

GoogleCodeExporter commented 9 years ago 
If I understood correctly, you can already do 
log.info("initial value of o us {}", o); 
Where the {} is replaced by the toString of o only if the level is set to info 
or lower.

So my point is that in all cases, {} in the default logger is the same as %s in 
the formatted logger. The only difference is that with {} you always get the 
toString. There might be some cases where you want to do better logging. But I 
think those are either rare, or won't be solved using the formatted logger 
anyway.

And yes, I am pretty sure you can come up with some cases where it makes a 
difference. But I think that those are not boilerplate, or common enough.

That said, I can imagine having the extra parameters in @Log4j2.

Original comment by r.spilker on 6 Sep 2013 at 10:38

GoogleCodeExporter commented 9 years ago 
To make it absolutely clear:

With the current lombok-generated code, you can already use {} for parameter 
substitution. The only thing the getFormatterLogger provides is to use a 
different syntax, the syntax from java.util.Formatter, allowing for a bit more 
control over the rendering of the values.

Original comment by r.spilker on 6 Sep 2013 at 10:40

GoogleCodeExporter commented 9 years ago 
Absolute it still relative :-)

You don't need getFormatterLogger to use {}. More strongly: getFormatterLogger 
does not support the {} syntax.

Original comment by r.spilker on 6 Sep 2013 at 10:42

GoogleCodeExporter commented 9 years ago 
So can this still be considered for adding.

Original comment by venkates...@gmail.com on 22 Nov 2013 at 5:42

GoogleCodeExporter commented 9 years ago 
Sorry, not really boilerplate and too little value for money. We've got loads 
of other stuff to do.

Original comment by r.spilker on 23 Jan 2014 at 7:06