Community
Participate
Working Groups
0.2 M5 Currently the server dumps a fair amount of tracing information to stdout. This should be disabled by default and configurable.
I have switched this tracing to use SLF4J. This seems the favourite logging API in the server world, and makes us consistent with Lucene/Solr. The tracing is disabled by default, but can be enabled from the logback.xml file.
(In reply to comment #1) > I have switched this tracing to use SLF4J. Does it apply to org.eclipse.orion.server.core.LogHelper as well?
(In reply to comment #2) > (In reply to comment #1) > > I have switched this tracing to use SLF4J. > > Does it apply to org.eclipse.orion.server.core.LogHelper as well? No, errors are still logged in the traditional .log file. I strongly believe tracing/debugging information like this should be kept separate from errors. I know SLF4J can also handle errors, and can be configured to write errors to a separate appender, but then we also have the problem of handling errors logged by other org.eclipse.* bundles we are using. I think it is easier to keep putting errors in .log, and any optional information that we want to be configurable can be done by SLF4J.
Makes sense to me , but I thought that in the future we could provide an implementation of FrameworkLog that logs using SLF4J. I'm still not sure if there is a way of disabling the currently registered log service (logging to .log file) or both implementation would have to coexist. IIUC, another option could be providing a SLF4J compatible logger that would delegate log calls to the service we're currently using. Until then, I will have to revert my fix to bug 335474 which logs error with SLF4J. I agree errors should be kept in one place.
