In 2008 I wrote a blog series about “Logging in OSGI Enterprise Applications” – you’ll find all informations here.
It’s worth to read the blog series again, because I don’t want to repeat it all, but in the meantime many things happened, so I want to tell you about my way to log in 2009.
OSGI Log Services
There are some different ways HowTo log in OSGI Enterprise Applications – but using OSGI means to use Services and OSGI and Equinox provide:
- OSGI Log Services: read the OSGI Compendium (I recommand Peter Kriens books found here) and use Log Services and Log Reader Services to log to the logging implementation of your choice
- Equinox Extended Log Services: same as ‘standard’ OSGI Log Services, but extends the Log Services and adds a ‘Logger’ object. I’m using Riena and Riena uses Equinox Extended Log Services from the beginning. Now – in Galileo – Equinox Extended Log Services has graduated and is part of Galileo, so its already built into Equinox. (Read more at Chris Aniszczyk blog)
Using OSGI Log Services you are able to log messages (OSGI Log Services) and to read those Log Entries (OSGI Log Reader Services), but is says nothing how to implement the logging to your backend of choice. And its also not a ‘you must use OSGI Log Services if you’re writing an OSGI Application‘. There are also good reasons to use a ‘classic‘ Logging framework directly. But you have to be aware that there are OSGI Log Services and you have to catch them. I’ll later explain how…
Fortunately there are some solutions available if working with OSGI Log Services:
- PAX Logging: PAX Logging integrates well into OSGI environments, uses Log4J as underlying Logging Framework. PAX Logging is a nice solution and if Log4J is the logging framework you’re using, then its a good idea to choose PAX Logging in your OSGI applications. (Read more at Patrick Paulins blog here)
- nogunner’s blog: here’s a blog-series HowTo use OSGI LogServices another way then PAX Runner or so do it – worth to read if you want to learn more about OSGI Log Services and perhaps nogunner’s way is your way.
Logging in OSGI Enterprise Applications
So – why another blog series, another solution ? why not choose one of the solutions above ?
You know – its all about ‘diversity‘ and perhaps my way of logging fits your needs, too.
These are some of my requirements:
- Logging in Eclipse Runtime (RT) Projects:
- Logging in Eclipse IDE
- Developing RT Applications (redView WYSIWYG Designer)
- Modeling Enterprise Applications (Eclipse Modeling, oAW, MWE, Xpand/Xtend, Xtext, EMF, redView, …)
BTW: I blogged about differences between IDE- and Target Platforms in detail in my blog-series about target-platforms.
Enterprise Applications always have to use and integrate many 3rdParty projects and not all provide well designed OSGI bundles. If you have to integrate those projects, you’ll find all possible ways of “how logging was used”:
- OSGI Log Services
- Equinox Extended OSGI Log Services
- Log4J
- SLF4J
- Apache Commons Logging
- JDK Logging (java.util Logging)
- ……
Even if you only have to integrate frameworks or tools already based on OSGI bundles, then you’re not always automatically ‘on the bright site of life‘ – sometimes you’ll get projects with a hard-coded dependency to a logging framework using Require-Bundle dependencies.
My wish to all Eclipse projects: please use import-package for common used Logging Frameworks (Apache Commons Logging, Log4J) otherwise there’s no out-of-the-box logging integration possible for consumers of those bundles.
Imagine: Bundle A says Require-Bundle: org.apache.commons.logging, but you’re using SLF4J where bundle jcl.over.slf4j provides apache commons logging packages using Export-Package: org.apache.commons.logging – this will only work if Bundle A uses Import-Package: org.apache.commons.logging because then its your choice to use Bundle org.apache.commons.logging or cl.over.slf4j as provider of commons logging implementation. These decisions have nothing to do with your preferences to prefer Require-Bundle or Import-Package – its a good practise to always use Import-package for commonly used packages.
Of course PDE makes it simple to ‘re-deploy’ bundles with a modified MANIFEST.MF but this is an extra step and I prefer to avoid this 😉
SLF4J as Logging API
Choosing the right Logging Framework API is the first decision you have to make and from my POV SLF4J is a good choice:
- SLF4J is already used by many frameworks and some (like Hibernate) just switched to SLF4J to provide more flexibility.
- SLF4J has bridges to integrate Log4J, Apache Commons Logging, java.util – Logging, …
- SLF4J is also used by PAX Logging
- SLF4J was developed with the experiences of Log4J in the background and from the same developers
- SLF4J lets you choose your Logging Implementation from:
- Log4J (PAX Logging per ex. uses Log4J with SLF4J API)
- Apache Commons Logging
- java.util Logging
- Logback
Logback as Logging Implementation
As next step you have to decide, which Logging Implementation to choose. In my projects I have selected Logback:
- Logback is the native SLF4J Implementation
- Logback supports all SLF4J features (like Markers, MDC, …)
- Logback is a completely rewritten Logging Implementation from the Log4J and SLF4J developers with one thing in mind: performance, performance, performance. (There’s video available about SLF4J and Logback)
- Logback implements SLF4J’s Markers help to use it together with OSGI Log Reader Services (will talk about this later)
- Logback has some great Appenders esp. if used in Enterprise Appliations
- Logback has a special Logback – Access module to support Servlet Containers like Jetty or Tomcat (this isn’t part of my blog series)
- Lilith provides a fast Socket Appender with a great UI tool to monitor Log events (something like Chainsaw for Logback) – very useful wether at development or at runtime
you’ll find the overview of this blog series here. stay tuned… part2 follows…
mobile && more 