Summary: | [components][dstore][api] Request a Logging interface, to be used in either client or server | ||
---|---|---|---|
Product: | [Tools] Target Management | Reporter: | Martin Oberhuber <mober.at+eclipse> |
Component: | RSE | Assignee: | Xuan Chen <xuanchen> |
Status: | NEW --- | QA Contact: | Martin Oberhuber <mober.at+eclipse> |
Severity: | enhancement | ||
Priority: | P4 | CC: | ddykstal.eclipse, dmcknigh, kjdoyle, uwe.st |
Version: | 2.0 | Keywords: | api |
Target Milestone: | Future | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: |
Description
Martin Oberhuber
2007-08-14 07:38:49 EDT
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 |