Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 336512

Summary:	[server] Allow tracing to be configured
Product:	[ECD] Orion	Reporter:	John Arthorne <john.arthorne>
Component:	Client	Assignee:	John Arthorne <john.arthorne>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	eclipse.felipe, Szymon.Brandys, tomasz.zarna
Version:	0.2
Target Milestone:	0.2
Hardware:	PC
OS:	Windows 7
Whiteboard:

Description John Arthorne

2011-02-07 09:58:27 EST

0.2 M5

Currently the server dumps a fair amount of tracing information to stdout. This should be disabled by default and configurable.

Comment 1 John Arthorne

2011-02-07 11:03:30 EST

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.

Comment 2 Tomasz Zarna

2011-02-08 05:00:59 EST

(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?

Comment 3 John Arthorne

2011-02-08 09:36:43 EST

(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.

Comment 4 Tomasz Zarna

2011-02-08 10:37:26 EST

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.