logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <carn...@apache.org>
Subject Re: Experimental log4j formatter in sandbox
Date Thu, 12 Jan 2006 23:25:18 GMT

On Jan 12, 2006, at 9:47 AM, Ceki Gülcü wrote:
>
> What is wrong with enshrining a solution that is optimized for the
> task at hand by being simple, easy to use and CPU effective?

If you are providing "one true way" of doing something (in this case,  
formatting messages for logging), then your definition of "task at  
hand" should be comprehensive.  The formatter in log4j 1.3 and SLF4J  
is okay as long as you are substituting strings at specific places,  
but is inadequate when, for example, you are using logging to track  
the convergence of iterative calculations.  In those cases, users  
would have a very legitimate desire to avoid unnecessary boxing of  
double and float values and would like to have the ability to control  
width and precision of the numeric fields.

> What
> advantages are there for your approach which offers 3 distinct
> solutions without committing to any of them?

The LogF class is preferable in general as long as the developer is  
willing limit their application to JDK 1.5 and higher.  With it they  
can use a pattern syntax that is similar to the C RTL printf and is  
the same as the String.format() and Writer.format() methods added in  
JDK 1.5.

The LogMF class would be useful for anyone who wants to maintain  
compatibility with earlier JDK's, but still wants the features of  
MessageFormat such as the ability to control width and precision of  
numeric fields.

LogSF was placed there as a potential migration path for code that  
used the log4j 1.3 pattern methods.  It should be fairly easy to  
write a regular expression that would change code that uses the log4j  
pattern methods to use LogSF.  I'm not suggesting at this point to  
vote on removing those methods, but this implementation was designed  
so that we could evaluate that option.


> By the way, an end-user
> can always implement the LogF or LogMF approach independently of what
> log4j 1.3 offers in agreement with the SLF4J API. Put differently, the
> LogF and LogMF code can always be implemented as a static utility
> class on top of log4j if need be.

That is exactly what the sandbox project is at the moment: a set of  
utility classes that can be used with log4j.  There should be an  
advantage for the community to review and refine these  
implementations and use them if they meet their needs.  If someone  
wants to create their own alternative formatters, there is nothing  
magic about them.


> However, by being aligned with
> SLF4J, log4j offers a stable solution and freedom of choice to its
> end-users.



>
> Curt has expressed reservations regarding the SLF4J approach.  Are
> there any other developers who are uneasy with the SLF4J approach? If
> my memory serves me correctly, Paul Smith expressed interest in the
> SLF4J approach. Are there any others?


On the slf4j-dev mailing list in August (http:// 
marc.theaimsgroup.com/?l=slf4j-dev&m=112327572703543&w=2), Joerg  
Hohwiller wrote:
>
> I actually got on the list with a very specific issue and my focus  
> lies
> on commons-logging, but anyways I want to point something out.
> You might find it strage that I, who proposed the need for additional
> methods in the Logger API, am saying this but:
> In my opinion a logger API should be very simple and focus on logging.
> What you are doing here is mixing logging with native language support
> (NLS, i18n or however you call it). In my oppinion this is  
> misplaced in
> a Logging API (I mean all the formatting methods).

...

> This is all about "separation of concerns".
> But again you see I am one of these IoC container guyz and care very
> much seperation of components and decoupled logic - maybe too much :)
> Other people just want to have things done quickly and without  
> using and
> understanding frameworks or stuff like this and they might like to  
> type
> it like suggested above.
> Anyways if you make it this way: the syntax with "{}" for me looks  
> like
> you are NOT using java.text.MessageFormat. Why is that? You do not  
> need
> to reinvent the wheel here. But maybe I am missing something.

and in (http://marc.theaimsgroup.com/?l=slf4j-dev&m=112328325919649&w=2)
>
> MessageFormat is a standard so many people know its syntax. It is more
> powerfull that just doing the replacement of a variable. BTW It also
> solves some NLS issues.

End of quotes from Joerg Hohwiller

>
> The assumption is largely correct except that the formatting cost
> should not be prohibitive compared to the cost of appending. Given its
> simplicity, the SLF4J approach is designed from the ground up to
> ensure optimal performance for this particular case.

One of the things I'd like to collect in the performance analysis is  
some quantification of the performance of java.text.MessageFormat.   
I'd think that it would have to be pretty naively implemented to be  
very much slower than org.slf4j.impl.MessageFormatter and maybe  
earlier performance problems have been addressed in the current JDK's.


In http://www.bejug.org/confluenceBeJUG/download/attachments/3845/ 
Log4JSLF4J-CekiGulcu.pdf?version=1, one of your slides said:

Why not use java.text.MessageFormat?
• Performance, performance, performance.
• Parameterized messages exist solely to
augment performance, the extra
functionality offered by
j.t.MessageFis deemed
superfluous.

I have never seen numbers that quantify the relative cost of calling  
java.text.MessageFormat.format() vs  
org.slf4j.impl.MessageFormatter.format() relative to the cost of  
something like overall append cost for NullAppender.



>
> The current log4j 1.3 implementation supports 1 or 2 parameters.
> The SLF4J implementation supports any number of parameters.

Sorry, must have looked at an old version of  
org.slf4j.impl.MessageFormatter.

>
>> The implementation is
>> different and may need to be tweaked to exactly reproduce the log4j
>> 1.3 and SLF4J behavior.  For example, LogSF doesn't attempt to
>> provide any escaping mechanism to allow "{}" to appear in a
>> message.   I'm not sure if log4j 1.3 or SLF4J do.
>
> Both log4j 1.3 and SLF4J allow "{}" to be escaped. This is easy to
> verify by looking at org.slf4j.impl.MessageFormatter present in both
> SLF4J and log4j 1.3.
>

I was admitting that I did a quick and dirty on LogSF and would need  
to go back and check the edge cases.



> See
> http://svn.slf4j.org/viewcvs/slf4j/trunk/src/java/org/slf4j/impl/ 
> MessageFormatter.java
> for more details.




---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


Mime
View raw message