Logging RCP applications with Pax Logging

July 14, 2009

Adding logging to an RCP application has always been painful. Developers have struggled with the best way to incorporate Log4J and other logging APIs, and in particular with how to make configuration files accessible. Some have chosen to use buddy classloading, others have utilized fragments containing the config files.

Pax Logging to the rescue

I’m happy to say that RCP developers now have another choice – Pax Logging. There are a few great things about this library:

  • Installation is easy. I’ll describe this in a bit.
  • Configuration files can be placed in regular folders, either inside of an application bundle or anywhere on a users machine.
  • Many logging APIs are supported, including Log4J, Commons Logging, JDK Logging, SLF4J and more. This means that legacy and third-party code can run as-is no matter what logging API they use.

Logging configuration with Pax ConfMan

Because Pax Logging requires the OSGi Configuration Admin service to work, your first step is to install this service in the form of Pax ConfMan. In my last blog post I provided detailed instructions on how to do this.

Adding configuration settings

The good news is that once you install Pax ConfMan, you’re almost done! Pax ConfMan requires the Pax Logging bundles in order to work, so we only have a few minor steps left.

The first is to add a logging configuration file. When using the OSGi Configuration Admin service, services are identified using a persistent identifier, or PID. Developers can choose the PIDs for their own services, and an implementation of the Config Admin uses these PIDs to inject properties into services.

Pax ConfMan does this by requiring that a properties file be named based on the PID of the service it is going to configure. For example, the Pax Logging PID is org.ops4j.pax.logging and so the properties file for this service will be called org.ops4j.pax.logging.properties.

If you created the folder structure suggested in the Pax ConfMan setup, simply create a file called org.ops4j.pax.logging.properties in the confadmin/services directory. You can now place whatever logging configuration you like into this file. For instance, here’s what I have for my simple test project:

log4j.rootLogger=DEBUG, A1

log4j.appender.A1.layout.ConversionPattern=%-4r [%t] %-5p %c %x - %m%n


Forcing Pax Logging to start

Just as we did with Pax ConfMan, its necessary to force Pax Logging to start up when our application is launched. To do this, we simply need add the org.ops4j.pax.logging.pax-logging-service bundle to the Configuration page of the Product Configuration Editor and set it’s Auto-Start property to true. If you’ve followed the instructions for installing Pax ConfMan, your complete list should look like this:


Fire it up

That’s all there is to it. Start up your RCP application and you should see log messages appear in your console.


Happy logging!

Adding Help to Eclipse 3.3 RCP Applications

December 13, 2007

The Eclipse help system changed dramatically in Eclipse 3.3, and it requires a new set of plug-ins to work correctly. There is little documentation about how to include the help system in an RCP application, though Kai Tödter was kind of enough to post a list of the correct help system plug-ins

I’ve taken that list and pared it down a bit (the Ant plug-ins are not necessary), and created a simple working example of an RCP app with integrated help. The example wraps the Eclipse help system in a feature called org.eclipse.help, which you can reuse in your own applications. There is some talk about making the help system an official feature in Eclipse 3.4, but for now the included feature should get you what you need. You’ll of course need to add the required plug-ins to your target platform, and if you’re curious, this is the final list:  

List of Plug-ins for Eclipse 3.3 Help System  

To get started, just download the example projects and import them into your workspace.

Getting started with PDE Build

June 6, 2007

I often work with teams getting started with Eclipse RCP, and the most common complaint I hear is that it’s too hard to set up automated builds. PDE Build can be frustrating to work with because it’s a black box. Your code goes in one side and a fully branded RCP application pops out the other. But if something goes wrong inside the box, where do you start to debug?

In my opinion, the best way to work with PDE Build is to get a very simple build running in your environment. Then make small, incremental additions, verifying the integrity of the process after each change. So the immediate problem for a team becomes: How do I get that first build running?

To help with this, I’ve put together a simple feature-based RCP product build. Just download and import the sample projects. If you follow the instructions in the included readme.txt file, you should have a build running fairly quickly. Before you know it, you’ll be seeing that always elusive BUILD SUCCESSFUL message flash across your screen!

Note: If you want to run this sample build using Eclipse 3.2, you’ll need to work around a PDE Build defect. For instructions on how to do this, check out the “Problems parsing feature file in a product build” section on the PDE Build wiki page.

Common Navigator Tutorial 1: Hello World

April 25, 2007

The Commons Navigator Framework is one of the more complex parts of the Eclipse API. It can be difficult to get started with the framework, and one of the hardest parts is simply getting a basic navigator to appear with custom content. This tutorial is designed to get you to that point so that you can start exploring the framework on your own.

There are quite a few steps, but it’s not as bad as it looks. So let’s get started!

Read the rest of this entry »