[prev in list] [next in list] [prev in thread] [next in thread] 

List:       logback-user
Subject:    RE: [logback-user] LOGBack and SLF4J make poor assumptions
From:       "Newcomb, Michael-P57487" <Michael.Newcomb () gdc4s ! com>
Date:       2007-08-02 13:00:51
Message-ID: 7E664C9A7DB0A942AB7AF0260D99AB8301529C5C () FL67EXM02 ! gddsi ! com
[Download RAW message or body]

--===============1329118777==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C7D505.27D29937"

This is a multi-part message in MIME format.


Um, no one is forcing you to use slf4j or logback...


________________________________

	From: logback-user-bounces@qos.ch
[mailto:logback-user-bounces@qos.ch] On Behalf Of
nospam.rwp@dsl.pipex.com
	Sent: Saturday, July 28, 2007 9:52 PM
	To: logback-user@qos.ch
	Subject: [logback-user] LOGBack and SLF4J make poor assumptions
	
	

	All,
	
	SLF4J and LOGBack are not backward compatible with Log4J,
despite what you say:
	

	1.	Dumping FATAL looks quite stupid to me, I use FATAL when
a Java Error is thrown or if my software has to quit early e.g. say it
runs out of disk space or can't write vital data to a file, I only use
ERROR for logging invalid data items, with WARN for duplicate data items
or data items values maybe suspect, some customers require this
precision so that their support staff only get called in for FATAL
issues.  Note Sun stupidly does not allow an ordered JRE shutdown, if
you call System.exit() with non-zero value, so the CLI return value is
not a viable alternative!
		
	2.	I always use the log methods with a Level because I need
the flexibility to set the log level on-the-fly for some situations, the
lack of log and fatal methods in SLF4J makes it unusable to me. 
	3.	LOGBack only provides Java 1.5 source code, which is
useless people who have to use Java 1.4 e.g. I have custom Log4J
Appenders which were only possible due to Java 1.4 compatible source
code, so no a Java 1.4 binary patch is not adequate. 

	I know you mean well, but professionals often have to work with
what is available on a system environment i.e. Java 1.4, so it is
annoying that API designers don't understand this.  It is often not time
effective to manually edit all the generics and incompatible classes out
of large code bases, in these case I have to blacklist affected APIs
until all our customers upgrade to Java 1.5.
	
	Richard
	
	
	


[Attachment #3 (text/html)]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.6000.16481" name=GENERATOR></HEAD>
<BODY text=#000000 bgColor=#ffffff>
<DIV dir=ltr align=left><SPAN class=557385612-02082007><FONT face=Arial 
color=#0000ff size=2>Um, no one is forcing&nbsp;you to use slf4j or 
logback...</FONT></SPAN></DIV><BR>
<BLOCKQUOTE 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
  <HR tabIndex=-1>
  <FONT face=Tahoma size=2><B>From:</B> logback-user-bounces@qos.ch 
  [mailto:logback-user-bounces@qos.ch] <B>On Behalf Of 
  </B>nospam.rwp@dsl.pipex.com<BR><B>Sent:</B> Saturday, July 28, 2007 9:52 
  PM<BR><B>To:</B> logback-user@qos.ch<BR><B>Subject:</B> [logback-user] LOGBack 
  and SLF4J make poor assumptions<BR></FONT><BR></DIV>
  <DIV></DIV><BR>All,<BR><BR>SLF4J and LOGBack are <B>not</B> backward 
  compatible with Log4J, despite what you say:<BR>
  <OL>
    <LI>Dumping FATAL looks quite stupid to me, I use FATAL when a Java Error is 
    thrown or if my software has to quit early e.g. say it runs out of disk 
    space or can't write vital data to a file, I only use ERROR for logging 
    invalid data items, with WARN for duplicate data items or data items values 
    maybe suspect, some customers require this precision so that their support 
    staff only get called in for FATAL issues.&nbsp; Note Sun stupidly does not 
    allow an ordered JRE shutdown, if you call System.exit() with non-zero 
    value, so the CLI return value is not a viable alternative!<BR>
    <LI>I always use the log methods with a Level because I need the flexibility 
    to set the log level on-the-fly for some situations, the lack of log and 
    fatal methods in SLF4J makes it unusable to me. 
    <LI>LOGBack only provides Java 1.5 source code, which is useless people who 
    have to use Java 1.4 e.g. I have custom Log4J Appenders which were only 
    possible due to Java 1.4 compatible source code, so no a Java 1.4 binary 
    patch is not adequate. </LI></OL>I know you mean well, but professionals often 
  have to work with what is available on a system environment i.e. Java 1.4, so 
  it is annoying that API designers don't understand this.&nbsp; It is often not 
  time effective to manually edit all the generics and incompatible classes out 
  of large code bases, in these case I have to blacklist affected APIs until 
  <B>all </B>our customers upgrade to Java 
1.5.<BR><BR>Richard<BR><BR><BR></BLOCKQUOTE></BODY></HTML>


_______________________________________________
Logback-user mailing list
Logback-user@qos.ch
http://qos.ch/mailman/listinfo/logback-user

--===============1329118777==--

[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic