JAX-WS error: java.util.HashMap cannot be cast to com.sun.xml.ws.transport.Headers

Happy Black Friday!

We are upgrading our JEE application from Weblogic 11g to 12c. On one of our staging servers, we got this error:

Java agent causing error: Caused by: java.lang.ClassCastException: java.util.HashMap cannot be cast to com.sun.xml.ws.transport.Headers

This error, however, doesn’t happen in our development environment. We have scratched our heads for many days for this issue. From googling, this link comes up at the top: http://www.ca.com/us/services-support/ca-support/ca-support-online/knowledge-base-articles.tec1210346.html This apparently indicates there are some jax-ws libraries that are polluting our environment in that staging server. Following this thought, we have tuned and reconfigured many ways to let the application use the jax-ws jar we want it to, in vain.

Eventually, a server admin found out that the Introscope Wily that is installed on the staging server is the culprit that contaminated the Java Classpath for the jax-ws. When we go back to the link above, that’s of course from Wily’s vendor CA! ! The fix is easy just follow the link above to change the introscope properties to what’s described in that link.

It’s ironic that the link is from CA at the first place, and it didn’t ring the bell for me that the issue was caused by Wily in the first place.

Cheers and happy holidays!



SOAP Webservice Streaming – Memory and CPU usage pattern

Hi, There:

I have recently implemented SOAP Streaming with CXF 3.14 and datahandler. The streaming works really well with huge payload in MTOM. Without detailing on the code in this post, let me show the memory/CPU usage in the application on the server side. The pattern on the client side is very similar too.

See the memory usage when streaming for 1 GB (first small oscillation) and 8 GB (second big oscillation) of payload. The heap memory is constantly using and releasing throughout the streaming process.  Meanwhile the CPU usage is heavy also due to the constant heavy IO, since streaming utilizes heavy temp file storage.

Not showing here, but for non-streaming SOAP MTOM, memory usage is pretty much a big lump without oscillation and its CPU usage is minimum due to limited processing and IO. During non-streaming, peak memory usage is much much higher than that of streaming since the whole payload is processed and contained in memory.





Weblogic 12C Maven Plugin Install and Setup

Hi, there:

A good day to try out Weblogic 12c with JDK8. Just can’t wait to try those stream with lambdas!   — Wait, where do I get the maven plugin for WLS 12c???

Oracle doesn’t host the maven plugins in central place. But both the pom and jar files are in a folder comes with the server. Run this mvn to install the plugin, assuming the server is in c:\bea12c.

cd c:\bea12c\oracle_common\plugins\maven\com\oracle\maven\oracle-maven-sync\12.1.3>

mvn install:install-file -DpomFile=oracle-maven-sync-12.1.3.pom -Dfile=oracle-maven-sync-12.1.3.jar

The pom.xml has the something like the following …




SSL issues by Soap Client from within Weblogic Server


Happy Chinese New Year!

Every problem that took me more than 2 days to find the solution deserves a writeup! This time it was a known issue when starts a SOAP request from a Webservice client from within Weblogic server, over HTTPS.  The problem I had was that we use a wildcard certificate for the receiving host, something like *.tonyyan.com, but the hostname is something like server1.tonyyan.com. WLS by default will fail the hostname verification process, hence fails the SSL handshake. There is a very nice link  http://jandrewthompson.blogspot.com/2010/04/weblogic-and-wildcard-ssl-certificates.html where it is described how to impl. and use a custom hostname verifier. However, I liked to use it just for my own client instead of changing verifier at the WLS server level. Thus, I used this code to by pass hostname verification all together (warning, this should not be used in PROD env, where some better and strict logic should be used to control wild card certificate against its hostname. Or, you could be vulnerable to man-in-middle attack).

BindingProvider bp = (BindingProvider)port;

// hostname issue – allow any hostname vs. its certificate
Map<String, Object> ctxt = bp.getRequestContext();

HostnameVerifier hv = new HostnameVerifier() {
public boolean verify(String urlHostName,SSLSession session) {
logger.info(“HostnameVerifier without validation.  urlHostName is ” + urlHostName);
return true;
ctxt.put(“com.sun.xml.ws.transport.http.client.hostname.verifier”, hv);
ctxt.put(“com.sun.xml.ws.transport.https.client.hostname.verifier”, hv);
ctxt.put(“com.sun.xml.internal.ws.client.hostname.verifier”, hv);

With this code, it still didn’t work for me. It turns out that I forgot to put the server certificate in WLS’ truststore, based on this order of usage of certificates.


After I put in the server certificate in DemoTrust.jks, things start to work great.