Thursday, January 26, 2012

Make your Application Server CXF JAX-RS friendly

Now and then I'm seeing users reporting issues on the forums to do with deploying web applications with CXF JAX-RS libraries into some of the popular Java EE application servers.

So I thought, while investigating a problem reported on the CXF users list to do with using a CXF Redirection feature in WebLogic, that it was also worth giving it a try and experimenting with deploying a complete OAuth demo web application packaged as a war archive that we are working upon into several popular application servers.

Initially I focused on testing Glassfish, JBoss and WebLogic and you can see the notes on how to overcome various deployment issues here.

It was a rather interesting exercise and I had few observations at a time.

WebLogic was the simplest to work with, as far as deploying the application was concerned without having to tweak anything at the container level. The management console of WebLogic is quite sophisticated and seems like this application server is still very capable. I only had to tweak the servlet configuration to get a CXFServlet using a wildcard URI pattern redirecting to WebLogic specific JSP engine properly as advised by the user who reported the issue.

Glassfish is OSGI-enabled and it was interesting to see Apache Felix serving as the default OSGI framework, which is a good news for the OSGI community at large, as it should drive the fixes back to this Apache project.

I had hard time though getting past the Jersey filter trying to deal with this application - it was failing eventually due to it not able to inject a CXF-specific JAX-RS Context instance. I only managed to get it work after removing one of Jersey jars from the available libs - one would only have to do it or may be something simpler :-) if the war has JAX-RS Application implementations and the OAuth demo has 5.

JBoss 7 was easy enough to deploy to. RestEasy also tries to load Applications but it was much easier to deal with it in JBoss. As a side note I thought the way JBoss 7 managed to move away from having to dump all the libs into common folders was very impressive. It is somewhat similar to the Apache Karaf's features mechanism, with Karaf having the repository of libraries and features linking those libraries together. In JBoss the repository itself has some additional metadata.

One thing I thought about after finishing this exercise was that the fact that the deployed applications are eagerly scanned for JAX-RS interfaces exposes a possible issue with these scanners. And the issue is that these scanners need to check if a deployed war contains a /META-INF/services/javax.ws.rs.ext.RuntimeDelegate resource or not and if it points to some alternative implementation then just leave this web application alone.

It would make it simpler not only for CXF JAX-RS users who may want to work with Glassfish or JBoss but for Jersey and RestEasy users too who may want to try the containers where either of this popular implementations is not natively supported. Besides, it would meet the general expectation that a self-contained war should be deployable to any Java EE container.

In meantime, please consider contributing the tips to this section. The tips in the WebLogic section have been provided on the CXF users list, so please keep them coming.