stillhacking

Last week was Google IO 2013.  I have to admit that although I have never attended Google IO, connecting with the keynotes and sessions via the web leaves me with a renewed sense of energy.  I have attended a significant number of other conferences and the positive, can-do attitude of the presenters goes a long way in my book. Sometimes in the day-to-day and week-to-week routine of our jobs we can lose a bit of the enthusiasm that comes with learning something new.  Regardless of one's profession, continuing eduction in a variety of formats is a very good thing indeed.  All this and no jet-lag. With Google IO fresh on my mind and the associated energy, I had a chance to play with a relatively new effort from Exadel  now called RESTXpress .  This software interests me on a couple of different levels and I applaud their initiative in releasing it as free software but I would like to see it as open sourced as well. If you have not yet seen this software, the video is wort

After writing my last post we had a short discussion about the endorsed directory and I realized I had neither fully explained the concept nor did I provide enough reference material so that it could be easily understood. This page  from Java 6 documentation technical notes explains it nicely.  The idea is you have a jar file which contains classes that you know should be used in place of the ones which are part of a particular version of Java. When I explained this in that short conversation I included the word "hack" because I was trying to convey the mess we may be creating: there is the very real possibility that other applications will be impacted because we are changing the Java runtime if Java is upgraded the "fixed" application may break again and the "fix" may be forgotten The bottom line is while I am glad Java has a convenient way to replace classes, I liken it to what I was taught about sudo'ing on Unix/Linux.  Respect it, use

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