Java 6 Broken Web Services

I would expect that the 1.6.0_03 to 1.6.0_04 JDK update would contain very minor bug fixes. Instead, it contains a major JAX-WS upgrade from JAX-WS 2.0 to JAX-WS 2.1. Ouch.

*** UPDATE ***

Someone pointed me to Java 6.4 is a whole new Java Release! Also, Rama disagrees in the comments on his blog. I stand by my original opinion that this change warranted more than an upgrade from _03 to _04.

Wouldn’t you know it…all of our web services (well, for one app, at least) broke. Why didn’t they call this 1.6.1?

Sample Code

Here is some sample code someone I work with sent me. This worked on JDK 1.6.0_03:

private void addHttpHeaders(final SOAPMessageContext context,
                            final String userName,
                            final String companyId,
                            final String enterpriseId) {
  //JDK1.6.0 - JDK1.6.0_03
  final MimeHeaders hd = context.getMessage().getMimeHeaders();
  hd.addHeader(USERNAME_HEADER, userName);
  hd.addHeader(COMPANY_HEADER, companyId);
  hd.addHeader(ENTERPRISE_HEADER, enterpriseId);
...

The point is to add custom HTTP headers. On the server, a Servlet filter intercepts these custom headers for some security-related functions.

With JDK 1.6.0_4, he had to change the code to this:

  //JDK1.6.0_04 - switch to JAXWS-2.1
  Map<String, List<String>> requestHeaders = (Map)
       context.get(MessageContext.HTTP_REQUEST_HEADERS);

  if(requestHeaders == null) {
    requestHeaders = new HashMap<String, List<String>>();
    context.put(MessageContext.HTTP_REQUEST_HEADERS, requestHeaders);
  }

  requestHeaders.put(USERNAME_HEADER,
      Collections.singletonList(userName));
  requestHeaders.put(COMPANY_HEADER,
      Collections.singletonList(companyId));
  requestHeaders.put(ENTERPRISE_HEADER,
      Collections.singletonList(enterpriseId));
}

New Way…Old Way…

To make this code portable across BOTH 1.6.0_03 and 1.6.0_4, he ended up leaving BOTH techniques in the code.

My Advice

This is just typical WS-* crap, in my opinion. It’s always very cryptic and complex, not to mention fragile if you try switching from one implementation to another. The promises never live up to the reality.

Thus, I use REST whenever possible.

Posted on Wednesday, February 27th, 2008 at 6:27 pm in Java, Software Development.