In my solution, I use JAXB to convert from XML over the wire into Java objects. I added the JAXB jars to my ear (as previously explained). When I deployed and tested the solution on my local server everything was fine.

When I deployed and tested the solution on the development machine, which contains WebSphere Application Server and the Oracle BPEL container, it didn’t work and threw the following exception:

javax.xml.bind.JAXBException: Unable 
to locate jaxb.properties for package com.twc.logging

This exception is very strange because the xjc compiler that I use to generate the JAXB classes from an XSD definition doesn’t generate a ‘jaxb.properties’. A search on google turned up?
the JAXB FAQ :
A thread on the sun java forums

The JAXB FAQ contains instructions to set the appropriate classloader so that the file can be found. I did this but it didn’t resolve my problem.

As I continued to scour the internet, it was strongly hinted that this was a required properties file in version 1.0 but is not present in 2.0. I decided to fire up my new best friend, Which4J to figure out which classloader was picking up the JAXB classes.

Sure enough, it turned out that there was an implementation of JAXB contained inside an oracle jar called ‘xml.jar’. Of course, the oracle container installed itself in the system classloader, so all of it’s jars are always on the classpath of all applications all the time. This means that no application that exploits JAXB 2.0 can be installed on the server.

We have a ticket open with oracle.

And since I’m on the topic of JAXB, the Unmarshaller is NOT thread-safe. I tried to save a line of code by storing it as a static reference in my class until my colleague pointed that fact out to me.