When using JAXB in an OSGi container it is important to load the JAXB context into the correct class loader. This is actually an issue with any framework that has not been release for OSGi and uses class loaders. I ran into this when trying to use Restlet's JAXB extension.

The fix is actually pretty easy. When using the JaxbRepresentation it's important to pass the current class loader to the constructor. I extended JaxbRepresentation to make the client code lighter. You can find the code for this below:

Feel free to use the above as you see fit.


One of the thing that can be a bit tricky when using JAXB is to map a java.util.Map to XML. In this example we have a provider object. The provider has a name and a map containing properties.

Below is the provider XML document:

And then the Provider class:

JAXB sees the properties object in the XML document as a list of property entries. Therefore we need to transform the list into a map. To do this we need three supporting classes. The first one is the class containing the entry, or property:

Next we need the class that contains the list of entries, or the properties:

To transform the list into a map we need an XmlAdapter. An XmlAdapter is a class that instructs JAXB on how to marshal and unmarshal an object that does not conform to the JAXB standard. This could for example be a class without a public no args constructor, or as in our case the provider properties map:

Now what is left is to tell JAXB to use the XmlAdaptor when handling the properties field. To do this we use the @XmlJavaTypeAdapter annotation. Below is the fully annotated Provider class:

I have finally install Java 7 on my laptop. The Java install runs just fine. Getting maven to find it however was a little tricky.

To make Maven find Java 7 the JAVA_HOME variable is required again. This hasn't been used for a while since Maven have been able to find Java anyway. But with the switch to 7 Maven still uses Java 6 by default.

I always use .bash_profile to change my environment variables since I tend not to need them else were. It is located in the users home directory (I.E. ~/.bash_profile).

The path to the new Java install is '/Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home/'. So the complete setting should look like this:


When this has been configured Maven will use Java 7.

Have you ever got a ClassNotFoundException when running tests and yet the dependency that contains the jar is clearly in your pom file? This is most commonly due to collations in transitive dependencies. If Maven cannot decide which version of a dependency to use it will not import it. It will expect you to sort the problem out first.

Handling transitive dependencies should always be done pro-actively. And there is some really good tooling for it. Being a IntelliJ/IDEA developer my self it saddens me to say that in this instance my favourite IDE is outdone by NetBeans. NetBeans uses Maven pom files as it's project descriptors which makes it very easy to open the project.

When the project is opened in NetBeans you will find the pom.xml file located under project files in the project navigator. Once opened you will find an item named "Show Dependency Graph" in the context menu. This will render a graphical representation of all the projects transitive dependencies.

If any of the dependencies has a red top left corner there is a version conflict. Resolving it is done quickest by opening the context menu for the dependency and selecting "Fix Version Conflict". Unless you have a specific preference that differs from the default suggestion in the dialogue it is usually fine to got with the default solution.

If any of the dependencies has a yellow top left corner there are more then one version of the dependency requested. Maven will always choose the latest version in the list. This can, and should, however be overridden using the exclusions tag. I tend to take control over all such dependencies buy making sure I clearly choose which one should be included. You have to do this manually by excluding the dependency from each of the dependencies where the version you do not want is included and then ensure that the dependency requiring the correct version is the only one still including it. Sometimes it's better to exclude it as a transitive dependency altogether and add it as a direct dependency.

Whenever a new dependency is added to the project I make sure to perform the same procedure to ensure that I have full control of the dependencies in my project.

I would be very pleased to find such a great tool in IDEA as well, then I wouldn't have to run two IDEs at the same time, they do require a lot of resources.

I am currently working with a REST application that uses JSON as it's data format. The Jersey framework offers this very nicely out of the box using annotations. The application is a front end that will have several different back ends depending on deployment. To simplify this I have chosen to use JSR-330, dependency injection from Java. The implementation is the Spring Framework.

It took me some time however to find out how to get Spring and Jersey to play together. I had to follow the following steps to get it all to run. I am using Maven 3 as the build and dependency manager.

To instantiate the Spring application context a specific servlet provided by Jersey is needed. To get the jar file we need to add the following dependency to our pom file.

Now we can replace the traditional Jersey servlet, com.sun.jersey.spi.container.servlet.ServletContainer, with one that also creates an application context, com.sun.jersey.spi.spring.container.servlet.SpringServlet in web.xml. Now the standard web.xml context configuration will be picked up:

With these changes done the Spring framework works as it always does.