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:
import org.eclipse.osgi.container.Module;
import org.eclipse.osgi.container.ModuleContainer;
import org.eclipse.osgi.container.ModuleContainerAdaptor;
import org.eclipse.osgi.container.ModuleContainerAdaptor.ContainerEvent;
import org.osgi.framework.Bundle;
import org.osgi.framework.BundleActivator;
import org.osgi.framework.BundleContext;
public class Activator implements BundleActivator {
private static BundleContext context;
static BundleContext getContext() {
return context;
}
public void start(BundleContext bundleContext) throws Exception {
Activator.context = bundleContext;
Bundle b = bundleContext.getBundle();
Module m = b.adapt(Module.class);
ModuleContainer container = m.getContainer();
ModuleContainerAdaptor adaptor = container.getAdaptor();
Throwable t = new Throwable("The error message.");
adaptor.publishContainerEvent(ContainerEvent.ERROR, m, t);
}
public void stop(BundleContext bundleContext) throws Exception {
Activator.context = null;
}
}
Tom
From: Thomas Watson/Austin/IBM@IBMUS
To: Equinox development mailing list <[email protected]>
Date: 05/16/2016 09:15 AM
Subject: Re: [equinox-dev] Safe logging from a WeavingHook?
Sent by: [email protected]
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. 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! :-)
Tom
From: Stephan Herrmann <[email protected]>
To: [email protected]
Date: 05/15/2016 07:07 AM
Subject: [equinox-dev] Safe logging from a WeavingHook?
Sent by: [email protected]
Hi,
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 ...
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
_______________________________________________
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
_______________________________________________
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
