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. Note that I do this only for illustration
in a bundle activator. There are lots of ways to get the container
in your framework extension:
Thomas Watson/Austin/IBM@IBMUS To:
mailing list <equinox-dev@xxxxxxxxxxx> Date:
05/16/2016 09:15 AM Subject:
Safe logging from a WeavingHook? Sent by:
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. 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.
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 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!
Herrmann <stephan.herrmann@xxxxxxxxx> To: equinox-dev@xxxxxxxxxxx Date: 05/15/2016
07:07 AM Subject: [equinox-dev]
Safe logging from a WeavingHook? Sent by: equinox-dev-bounces@xxxxxxxxxxx
When implementing a WeavingHook, is there a safe way to perform logging?
I'm asking because my current strategy recently broke when adding the AERI error reporter to the mix:
I'm acquiring a log basically from Platform.getLog(bundleContext.getBundle()) (with extra caution to see if the platform is ready).
This works well until others register log listeners of their own. Such breakage is tracked in https://bugs.eclipse.org/493566 showing a stack trace of what looks like deadly re-entrance, causing NoClassDefFoundError.
I know that the Equinox framework uses a logger of its own, which - I assume - does not support any log listeners, right? Is it possible for a weaving hook implementation to log into the framework log?
If no safe log is available, are there any points in the hook protocol, where it is safe to log using a platform log? I'm thinking of queueing log events until modified(WovenClass), but even during that method I don't know if any class loading is active further down the stack that may cause the same problem. Do I have to maintain my own thread-local stack of classes being defined to wait for a point when this stack is empty? Or is it possible to get this information from the framework?
Interesting, how such a basic functionality like logging can blow up a system, if both class loading and logging are extensible ...