Hi Tom, Thanks for your comprehensive answer. Yes, we can easily agree that SynchronousLogListener is dangerous :)
More questions inline ... On 05/16/2016 04:14 PM, Thomas Watson wrote:
Hi The Eclipse Log API (org.eclipse.core.runtime.ILog) has the unfortunate contract that log listeners registered with it will be called synchronously. This can cause the issues you are seeing with class loading if we get into a circularity. In Equinox we actually have one and only one log implementation and this is the OSGi LogService implementation. In Equinox we have an extension of the specification in the org.eclipse.equinox.log package. Here is where we have the interface org.eclipse.equinox.log.SynchronousLogListener which allows us to implement the contract of org.eclipse.core.runtime.ILog on top of. All other log APIs in Eclipse and Equinox are all implemented on top of this single OSGi Log Service implementation. In the extended API Equinox provides to the OSGi Service API we also have the concept of named loggers. Now the org.eclipse.core.runtime.ILogListener that are registered will only listen to a very specific logger named "org.eclipse.equinox.logger". This logger happens to also be the logger which also writes to the persistent log for eclipse. You could consider using the equinox extended log service instead by calling org.eclipse.equinox.log.ExtendedLogService.getLogger(String) and supplying your own logger name. Anything logged here will be sent to LogListeners asynchronously, unless you happen to have someone implementing the SynchronousLogListener and paying attention to your logger name.
Sounds promising, but ...
But be aware that nobody is going to see your logs until there is a org.osgi.service.log.LogService registered to listen to your logs.
... is that s.t. I have to register? How? Can I hook this up so that all entries do (eventually) appear in the Errors view and perhaps the persistent log file?
The one exception to this rule is when the LogEntry is of type ERROR, in that case the log will be sent to the persistent eclipse log file BUT it WILL NOT be sent to the listeners registered with the org.eclipse.core.runtime.ILog. I'm unsure what you are trying to log, but if it is simply ERRORs then I would use the standard org.osgi.service.log.LogService
I'm using it for all kinds of things. The particular dangerous case was logging profiling data at level INFO.
I should also mention that most all the concepts of the Equinox extended logger API in org.eclipse.equinox.log will be included in the future OSGi R7 specification. The one exception is the SynchronousLogListener, which I believe to be a dangerous thing to spec, and I think you may agree! :-)
On 05/16/2016 04:31 PM, Thomas Watson wrote: > I forgot to mention how the framework logs. Typically we do not actually log. Instead we publish framework events which get picked > up by the LogService implementation. Since you are a framework extension you could consider doing the same thing using Equinox > container APIs. The container allows for events of type error, warning or info. But not that again only the error types will get > written to the persistent eclipse log. One way to do this would be with the following code. Works nicely for ERROR, but again: can I achieve that also WARNING and INFO are "visible" to users? Right now they seem to go to /dev/null thanks, Stephan _______________________________________________ equinox-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev
