ClassCastException: JAXB
A particular Java application I co-developed leverages both SOAP/WSDL and REST web services. We use maven to manage the build process of this application which has been in production for a few years now. It's been around long enough to have moved from Java 5 to Java 6 and now Java 7 (with limited testing using Java 8). We have also had the experience of initially including JAXB jar files with our application and dealing with the "endorsed" directory because JAXB versions were a bit of a moving target for a while.
Now that JAXB is neatly included with Java as it should be so we no longer include it. I thought all of this was behind us (and unfortunately somewhat forgotten) until recently when we added Jersey 1.17 to the application to call some newer REST services.
When trying to connect to the server, my stack trace included this:
Caused by: java.lang.ClassCastException: com.sun.xml.bind.v2.runtime.JAXBContextImpl cannot be cast to com.sun.xml.internal.bind.api.JAXBRIContext
Jersey brings along with it JAXB-API and JAXB-Impl.
It did not take long to remember what was wrong but getting the build process to exclude these jars did confuse me for a bit (looking back I'm not sure why but I hope this will help someone at some point). I was focused on the jnlp folder in the target directory because it contained the two jar files. This in turn caused me to look at the configuration for the JNLP/WebStart plugin (webstart-maven-plugin) for some time.
As it turns out the simple solution is to exclude the jar files on the dependency itself, in this case jersey-json.
NetBeans makes cleaning this up a breeze. Right click on the dependency and select Exclude Dependency.
After excluding both jars, that section of my pom file looks like this:
The code that NetBeans added is highlighted in blue. Sure, you can add this to your pom file manually and I imagine Eclipse and IDEA IDEs have similar help but I have not looked lately. Another feature available in NetBeans which may help find a similar problem is the information contained in the hints for each dependency. Placing your mouse cursor over a dependency will provide some nice reminders including the source of transitive dependencies.
In summary this little experience is a reminder that my IDE, in this case NetBeans, can help me recall some stuff I know (or at least once knew) but don't use everyday and therefore can save a bunch of time in the long run.
HTH,
Carl
Now that JAXB is neatly included with Java as it should be so we no longer include it. I thought all of this was behind us (and unfortunately somewhat forgotten) until recently when we added Jersey 1.17 to the application to call some newer REST services.
When trying to connect to the server, my stack trace included this:
Caused by: java.lang.ClassCastException: com.sun.xml.bind.v2.runtime.JAXBContextImpl cannot be cast to com.sun.xml.internal.bind.api.JAXBRIContext
Jersey brings along with it JAXB-API and JAXB-Impl.
It did not take long to remember what was wrong but getting the build process to exclude these jars did confuse me for a bit (looking back I'm not sure why but I hope this will help someone at some point). I was focused on the jnlp folder in the target directory because it contained the two jar files. This in turn caused me to look at the configuration for the JNLP/WebStart plugin (webstart-maven-plugin) for some time.
As it turns out the simple solution is to exclude the jar files on the dependency itself, in this case jersey-json.
NetBeans makes cleaning this up a breeze. Right click on the dependency and select Exclude Dependency.
After excluding both jars, that section of my pom file looks like this:
In summary this little experience is a reminder that my IDE, in this case NetBeans, can help me recall some stuff I know (or at least once knew) but don't use everyday and therefore can save a bunch of time in the long run.
HTH,
Carl
Comments