Logging in OSGi and eclipse RCP

I’m further along with logging in an OSGi environment especially eclipse RCP. I found these blogs that are very useful:

The real issue is that OSGi is a much stricter environment in terms of how the classpath is built and hence, the standard logging and logging facades (like slf4j) do not work properly in a strict OSGi environment. Eclipse equinox provides some relief through equinox specific or eclipse specific mechanisms but we need a logging solution that can operate in a strict OSGi environment but integrate multiple logging and logging facade APIs because most likely, in any decent sized application, you will need to manage multiple logging ecosystems within subsystems such as hibernate or spring.

What does eclipse’s equinox do?

First, before equinox was used for plugins in eclipse, there was a logging mechanism already in place. Typically, in most applications, you would define a master logging method in the plugin class specific to your bundle to help with general logging using IStatus.

   1: public static void log(String message) {
   2:         getDefault().getLog().log(
   3:                 StatusUtil.newStatus(IStatus.ERROR, message, null));
   4:     }

or at least something like this. The actual interface obtained from the plugin was ILog which is an object created by the eclipse runtime for each bundle. Note that if you used this interface you are tied to the eclipse platform which for UI plugins is okay but for general subsystems that may have usefulness outside of eclipse would be bad. The class org.eclipse.core.internal.runtime.Log implements ILog and this Log class uses an internal eclipse platform logger: InternalPlatform.getDefault().log(status); and it also runs the logged message through and specific bundle-level listeners. The InternalPlatform object uses a RuntimeLog object which essentially broadcasts/multiplexes the log message to all listeners at the platform level. The javadoc suggests that this class is to be replaced at some point. Two primary listeners at the platform level are defined, a status manager listener StatusManager.StatusManagerLogListener which puts status messages into an eclipse view, and a LogWriterwhich is a bridge between the platform and OSGi (some day) framework logging. The LogWriter writes to another interface for OSGi called org.eclipse.osgi.framework.log.FrameworkLog. There are two implementations for this interface, one that is an anonymous class that acts as a default OSGi logger that merely prints to System.err and a second that is called EclipseLog that writes to a file or some other OS specific location. This logger is brought in through the framework adapter which adapts the framework to a specific OS. FrameworkAdapter is an interface that allows more extensions to a platform and this defines a method to obtain a framework log through FrameworkAdapter.createFrameworkLog(). Different framework log implementations exist (several in fact) but many do not define an additional logging mechanism.



Based on code inspection it does not appear that eclipse use the OSGi logging service yet or perhaps never. However look here: http://eclipsesource.com/blogs/2009/03/24/tip-osgi-log-service/ and you can see that equinox does implement logging and extended logging services. Here’s the equinox home page: http://www.eclipse.org/equinox/bundles/. The logging service code is deleted (!) because they just switched to a newer logging service implementation. Here is the bug report that shows the extended log service (compatible with basic OSGi I believe) and says that eclipse does not use OSGi logging yet: https://bugs.eclipse.org/bugs/show_bug.cgi?id=260672. If you want to use this implementation but still use slf4j API, you will need a bridge between the two.


There are different ways to create the bridge. One can load up on slf4j in your own modules and use bridges to the slf4j interfaces that came from the slf4j home page. Then you can use a slf4j to osgi bridge that shoves all messages into the OSGi logging service. Then you can have a bridge between the OSGi logging service and logback (for example). Or you can everything, including OSGi logging services, go to the logback logging engine directly. The biggest issue I see with throttling everything OSGi logging services is that there is less chance for optimization and logging will take up more CPU and memory cycles—which may or may not be a big problem for your application.


The slf4j website has a svn (and perhaps built plugin) that has OSGi logging over slf4j. If you use this plugin, you still need to provide a slf4j logging implementation.

Comments

Post a Comment

Popular posts from this blog

quick note on scala.js, react hooks, monix, auth

quick note on scala.js, react hooks, monix, auth Reactjs hooks finally came out of preview in a recent version of React. scalajs-reaction has had support for hooks since they were in preview. React hooks seem like the hot new thing but for me the question is, do hooks help improve your code by improving maintainability, time to market, TCO, etc.? Let’s take a look using authentication as an example and employ monix , a reactive observable framework that also builds on cats . We will assume we are building a SPA. Does it improve your code and make your application & development experience better? Auth Auth processing can be complex. Many react auth examples you find in blogs like to show how to use “react-routing” and “auth” as a switch that determines which routes are protected or unprotected. Protected routes show application specific data. Unprotected routes show login content . Based on storing a “User” object in the browser session/local storage, th...
Read more

zio environment and modules pattern: zio, scala.js, react, query management

zio environment and modules pattern: zio, scala.js, react, query management This blog covers a zio-based fetch design for scala.js, react web applications. It heavily uses the zio “environment” feature to help motivate a point of view on the modules pattern in effect systems. At the end, I summarize some thoughts on ergonomics and complexity. This blog assumes a basic knowledge of zio and react. scala.js is just like scala so you mostly already know scala.js. This blog is a follow-on to previous blogs: https://appddeevvmeanderings.blogspot.com/2019/10/scalajs-react-fetcher-hook_48.html and https://appddeevvmeanderings.blogspot.com/2019/11/scalajs-and-react-suspense.html . I have been keeping an eye on and culling ideas from typscript/javascript fetching libraries that address query management concerns. The formulation below incorporates some of those concerns but does not try to comprehensively duplicate well established javascript libraries. I only care about ...
Read more

attributes with react and typescript.md

If you use typescript with react you may wonder what the right signature is for your “properties” interface. Obviously, your component will have few to many specific properties that reflect your domain. However, you may wish to also provide for the ability to add other attributes, such as those valid for a div property. In other words, you want to extend your props interface with that of the properties from a div element. How do you do that? There are really two issues: How do you extend your props interfaces How do you filter the props once you receive them to just those that apply. Extend Your Prop Interface or Use Sum Types It’s not uncommon to see interface Props { className ? : string yourProp ? : number } with the idea of using it in class MyComponent extends React.Component<Props, any> somewhere. If your component will have an outer div, you may also pass in a react element so that its configurable. But let’s say your outer element is a div and you wan...
Read more