Community
Participate
Working Groups
There are cases like the archive handlers, which can run either inside the dstore server, or in the RSE client. If such code wants to log debug messages or other information, it has no means of querying the current logging level or actually doing its logging: see bug #199065 comment 1 -- the Server should use UniversalServerUtilities, but the client should use SystemBasePlugin. Because of different class path and dependencies, none of these methods can be used directly. What we need is a simple universal interface, similar to org.eclipse.rse.core.Logger, but without any Eclipse dependencies and declared in the clientserver package: interface ISystemLogger { int getDebugLevel(); int getDebugLevel(String component); void logError(String, Throwable); void logWarning(String, Throwable); void logInfo(String, Throwable); } Then, have that interface implemented by both the client logger and the server logger. Now, at the time the archive handlers are registered, the logger can be registered as well: ArchiveHandlerManager.registerLogger(ISystemLogger theLogger);
Note that another option, though more heavy-weight, might be to use a standard means of logging e.g. org.apache.log4j or org.apache.commons.logging, or the JRE java.util.logging facilities.
Given that dstore only runs on Java 1.4 JVM's, I think that actually using java.util.logging is the right solution for this. This would allow nicely configurable logging in the server through the Sun JVM Logging API which already exists; by default, the dstore server would log to stdout as it does now, but users could easily configure it to log to a file or somewhere else, just by using the readily-documented java.util.logging Property Files. The client could register a logging handler which logs all the ArchiveHandler stuff to the Eclipse logs. And all that could be done without any API changes. For a description of the java.util.logging framework, with some nice examples, http://java.sun.com/j2se/1.4.2/docs/guide/util/logging/overview.html#2.0 is a good reference. Each ArchiveHandler would simply do this: private static Logger logger = Logger.getLogger("org.eclipse.rse.archives"); and instead of System.out.println() in case of errors, it would do this: logger.log(Level.WARNING,"trouble sneezing",ex); While the dstore server would not register a specific handler (so logging would go to stdout in the server as now), the RSE client would declare an Eclipse Logger Handler, and register it: class EclipseLogHandler extends Handler { ... } Logger rseLogger = Logger.getLogger("org.eclipse.rse"); Handler eclipseHandler = new EclipseLogHandler(); rseLogger.addHandler(eclipseHandler);
For a nice description of various logging scenarios, what can or should be logged and how logs can be used, see http://java.sun.com/j2se/1.4.2/docs/api/java/util/logging/package-summary.html#package_description
It would be nice to have this in 2.0.1 - and it would be actually possible since no API is changed - but I think there are other issues with higher priority to be resolved.
I would support the idea of using java.util.logging instead of any other additional/3rdParty logging mechanism (log4j or commons.logging) as standard in RSE. And we should make sure that at least all non-UI components do log anything using that standarized way. Especially if RSE somewhen should be capable of running headless, the separation of the event logging vs. event presentation (dialog vs. error log) is very important. We don't want to spread that complexity to every one developing with or for RSE, do we?
Yes, as the UI/Non-UI separation of RSE is further improved, we might think about using java.util.logging in other parts as well. My personal feeling, though, is that the current org.eclipse.rse.logging package (which resides in org.eclipse.rse.core so it only has dependencies on eclipse.core.runtime plus a weak one on eclipse.core.resources) should suffice for even non-UI RSE services on the client. java.util.logging does provide better tracing, filtering and redirection capabilities for the logs; but as the client is all inside Ecipse, using the Eclipse mechanisms (Logs and tracing) for this seems sufficient. The only place where I see a real need for java.util.logging is those parts of the code which can also run in the (dstore) server where no Eclipse mechanisms are available. Or do you see cases where the Eclipse logging and tracing facilities are not sufficient in the client?
Possible use java.util.logging interface to implement a server side logging directly to files on the server. Client side logging would be directed to the current logging interface by this as well. Also look at apache commons logging for CBE logging that could be interpreted by TPTP.
Bulk update target milestone 2.0.1 -> 3.0
