[slf4j-user] Avoiding new line after log messages

[Jacob Kjome]

On Fri, 04 Jan 2008 20:04:25 +0100
  simon <skitching at apache.org> wrote:
> 
> On Fri, 2008-01-04 at 12:16 -0600, Jacob Kjome wrote:
>> On Fri, 04 Jan 2008 18:54:06 +0100
>>   simon <skitching at apache.org> wrote:
>> > 
>> > On Fri, 2008-01-04 at 11:32 +0100, Guy Pardon wrote:
>> >> Is there a way to log multiple strings in different calls to the
> SLF4J  
>> >> API, without a newline in between?
>> > 
>> > No.
>> > 
>> 
>> What do you mean "No"?  That's up to the logging implementation
> configuration, 
>> isn't it?  SLF4J, unless it is just the simple one that does
> System.out, has 
>> nothing specifically to say about newlines.
>> 
>> That said, the layout assigned to an appender would need to not define
> the 
>> newline.  That would mean that the developer would need to include a
> newline 
>> as needed when performing logging statements.
> 
> Well, either 
> (a) SLF4J buffers/merges messages and only passes them through to the
> underlying system once a message is complete, or 
> (b) SLF4J passes them through immediately, but the underlying logging
> lib merges them, or
> (c) SLF4J passes them through immediately and an appender of the
> underlying logging lib merges them.
> 

Ok, ok, mea culpa.   You can't *guarantee* it for all the reasons you state. 
 My point is that SLF4J doesn't add newlines itself per logging statement. 
 And if your own code is the only thing doing the logging and these come out 
in the appender (having a layout defined without a newline) in the same order 
they were originally logged, there's no reason I can think of that they would 
have newlines in them unless they were added to the logging statement itself. 
 They would, in fact, be part of a single line, even though they came from 
separate logging statements.

I'm not trying to argue that this is a proper thing to do, only possible. 
 Your point about using the StringBuffer to gather up all strings and then, 
finally, output as one logging statement is exactly correct.  No argument 
here.  But at the same time, "No" is not a fair answer.  The users question 
was about whether it was possible.  You said "No", which is flatly wrong.  The 
correct answer is "Yes, but YMMV so use a StringBuffer and a single logging 
statement instead to guarantee expected behavior".

Jake


> Option (a) is theoretically possible, but I can definitely say that no
> such feature currently exists. And I think it would be a bad idea. If
> code logs several "parts" then fails to do the "flush" then the whole
> message gets lost. Plus it adds complexity to the "logging adapter"
> layer that almost nobody will use.
> 
> Option (b) and (c) are not feasable because how an app logs is
> determined by the app programmer but what logging lib/adapters are
> configured are determined by the app deployer. There is no cross-library
> convention for merging messages, so the application doing the logging
> will never know whether the lib/adapters available at runtime are
> capable of merging messages or not.
> 
> And furthermore, I can say that I am not aware of any such "message
> merging" functionality in log4j or the java.util.logging implementation.
> 
> So I think "no" was a pretty fair answer.
> 
> If someone wants to merge several strings into a message, then they
> should use a StringBuffer, and then log its contents once everything
> necessary has been collected. As one atomic log call.
> 
> Regards,
> 
> Simon
> 
> 
> _______________________________________________
> user mailing list
> user at slf4j.org
> http://www.slf4j.org/mailman/listinfo/user
>