[Javapathfinder-devel] javapathfinder/env/jpf/java/lang Class.java,1.2,1.3

[pcm <pcm...@us...>]

Update of /cvsroot/javapathfinder/javapathfinder/env/jpf/java/lang
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv30521/env/jpf/java/lang

Modified Files:
	Class.java 
Log Message:
this is the advent of the Debug replacement. We are using a conventional log scheme that actually piggybacks on java.util.logging, even though we don't really use logger hierarchies, we have our own initialization scheme, and we use our own log handler class. The reason for this is that we still want to maintain a single configuration scheme, and we want to be able to log to three different output destinations (hostname:port, file, out/err) without requiring to change class names in a logging.properties file. The handler is still very primitive in terms of output formatting, and the config consists of the following entries

# what is our default level for unspecified loggers
log.level=<defaultLevel>

# where to log to
log.output=<filename> | out | err | <hostname>:<port>

# logger specific levels
log.severe=<logger-pattern>{:<logger-pattern>
log.warning=..
log.info=..
log.config=..
log.fine=..
log.finer=..
log.finest=..

There is a new class gov.nasa.jpf.tools.LogConsole that can be used to display socket logging. This is now also meant to be used for the SearchMonitor. With this in place, Debug statements will now be replaced with the standard java.util.logging.Logger API, i.e.

static Logger log = JPF.getLogger("gov.nasa.jpf.<whatever>");
..
log.severe(msg); .. log.info(msg); ..

There is one caveat to notice: since Config results are reported by means of the logging facility, but the logging is configured via Config (single source), the Config initialization (ctor) is not allowed to produce logging output, but rather has to preserve all states, failures etc. for subsequent reporting (by JPF). This is less than optimal from a design point of view (cyclic dependency), but the user-friendly pinciple of a single config source overrides this.

Second caveat is that log output should be event based, not line-by-line, which means there is an increased tendency to see hidden StringBuffer use. If there is a good chance the log level will not be set, this should be wrapped for efficiency reasons in

if (logger.isLoggable(Level.<whatever>)) {
  logger.fine("Blah " + gna + '\n' + 
                    "another line");
}

The scheme could be extended to enable logger specific output (i.e. one console for vm, another one for a listener etc.) , and the console to allow multiple simultaneous connects, but we leave that for later (if it really makes sense). For now it is important that we can replace the Debug statements.

Index: Class.java
===================================================================
RCS file: /cvsroot/javapathfinder/javapathfinder/env/jpf/java/lang/Class.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -d -r1.2 -r1.3
--- Class.java	5 May 2005 01:03:54 -0000	1.2
+++ Class.java	18 May 2005 06:41:46 -0000	1.3
@@ -24,6 +24,7 @@
 import java.lang.reflect.Field;
 import java.lang.reflect.Method;
 import java.lang.reflect.Constructor;
+import java.net.URL;
 
 /**
  * MJI model class for java.lang.Class library abstraction
@@ -73,6 +74,10 @@
     throw new JPFException("Class.getResourceAsStream() not yet supported");    
   }
   
+  public URL getResource (String name) {
+    throw new JPFException("Class.getResource() not yet supported");    
+  }
+  
   public Constructor getDeclaredConstructor (Class[] paramTypes)
               throws NoSuchMethodException, SecurityException {
   // <2do>