RE: PATCH: Priority.java : add method Priority toPriority(int, Pr iori ty)

[Kitching Simon <Si...@orange.ch>]

> -----Original Message-----
> From:	Ceki Gülcü [SMTP:cgu@urbanet.ch]
> Sent:	Tuesday, February 06, 2001 3:52 PM
> To:	LOG4J Developers Mailing List
> Subject:	Re: PATCH: Priority.java : add method Priority
> toPriority(int, Priori ty)
> 
> 
> I agree that the lack of the Priority.toPriority(int intLevel, Priority
> default) is asymmetric when compared to the Priority.toPriority(String)
> variant. However, do you actually make use of the int variant?
> 
> As far as I know, the int form is called when serializing an event. Is it
> used anywhere else? Can you give an example of where this asymmetry poses
> a problem? Thanks, Ceki
	[Kitching Simon]  

	No, I don't know of any situation other than 
	deserialization where the doPriority(int) method 
	is called (in fact, I didn't even realise that 
	serialisation was the reason for that method's 
	existence).

	The only problem is that the code for a custom 
	Priority object looks wrong. I was writing my custom
	Priority, and saw that *if* my overridden string-based
	method was called with a bad string, I returned my
	DEBUG2 priority (lower than DEBUG), but for the int 
	case my code didn't have an equivalent way to handle
	the error; Priority.DEBUG would always be returned.

	It seems to me that if there is error-handling code in 
	org.apache.log4j.Priority, even if this code is never 
	expected to be called, then the derived classes
	should be given the chance to customise it..

> ps: Otherwise, I think the patch is very reasonable. :-)
	[Kitching Simon]  
	Though not very important :-)

> At 14:09 06.02.2001 +0100, you wrote:
> 
> >The standard Priority class implements
> >
> >Priority toPriority(String level)
> >and 
> >Priority toPriority(String level, Priority default)
> >
> >It also implements
> >Priority toPriority(int intLevel)
> >but ****not****
> >Priority toPriority(int intLevel, Priority default)
> >
> >The lack of this last method causes problems when 
> >defining custom priorities; the derived priority class
> >typically calls the inherited method if it doesn't understand
> >a level string or int it is passed, but because of the lack of
> >a default parameter, it cannot control what default value is
> >used if toPriority(int) is called with a totally unknown int value.
> >
> >It's also a little inconsistent/asymmetric not to have the
> >Priority toPriority(int intLevel, Priority default) method defined.
> >
> >Example of custom priority class making use of this patch:
> >
> >Proposed patch:
> >
> >
> >Index: Priority.java
> >===================================================================
> >RCS file: /home/cvspublic/jakarta-log4j/org/apache/log4j/Priority.java,v
> >retrieving revision 1.5
> >diff -u -r1.5 Priority.java
> >--- Priority.java       2001/01/19 16:45:28     1.5
> >+++ Priority.java       2001/02/06 13:05:47
> >@@ -134,20 +134,30 @@
> >   }
> > 
> >   /**
> >-    Convert an integerq passed as argument to a priority. If the
> >-    conversion fails, then this method returns {@link #DEBUG}.      
> >+    Convert an integer passed as argument to a priority. If the
> >+    conversion fails, then this method returns {@link #DEBUG}.
> > 
> >   */
> >   public
> >   static
> >   Priority toPriority(int val) {
> >+    return toPriority(val, Priority.DEBUG);
> >+  }
> >+
> >+  /**
> >+    Convert an integer passed as argument to a priority. If the
> >+    conversion fails, then this method returns the specified default.
> >+  */
> >+  public
> >+  static
> >+  Priority toPriority(int val, Priority defaultPriority) {
> >     switch(val) {
> >     case DEBUG_INT: return DEBUG;
> >     case INFO_INT: return INFO;
> >     case WARN_INT: return WARN;
> >     case ERROR_INT: return ERROR;
> >     case FATAL_INT: return FATAL;
> >-    default: return DEBUG;
> >+    default: return defaultPriority;
> >     }
> >   }
> > 
> >@@ -171,5 +181,6 @@
> >     if(s.equals("FATAL")) return Priority.FATAL;
> >     return defaultPriority;
> >   }
> >+
> > 
> > }
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
> 
> ----
> Ceki Gülcü           e-mail: cgu@urbanet.ch (preferred)
> av. de Rumine 5              ceki_gulcu@yahoo.com
> CH-1005 Lausanne          
> Switzerland            Tel: ++41 21 351 23 15
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: log4j-dev-help@jakarta.apache.org