Awhile back I posted an entry on how to get CXF JAX-RS loaded successfully within your favorite Java EE application container, and specifically within the containers like JBoss or Glassfish which have their preferred JAX-RS implementations actively supported.
I think it was a good enough initial step but it proved to be quite incomplete, with users reporting CXF failing to handle the objects of some of JAX-RS core types like Response.
In this rather technical post I will give an update on the situation.
What typically happens is that when Glassfish or JBoss loads a CXF-enabled application, the active subsystem (Jersey or RestEasy based) will still intercept the runtime or application code doing a code like "Response.ok().build()" - this static sequence of calls will end up being processed by this subsystem which leads to a somewhat unusual case, where the CXF runtime ends up processing 'foreign' JAX-RS Response objects - attempting to cast to the CXF-aware Response object breaks the application.
So what we've decided to do now is to start working on making CXF JAX-RS completely isolated from the loaded third-party JAX-RS libraries, by minimizing and when possible completely removing the calls like "Response.fromResponse" which lead to the 3rd party subsystems intercepting the control. This makes CXF JAX-RS more robust when loaded alongside other JAX-RS runtimes, and also marginally faster - the cost of getting from the static code sequence to the actual Response builder implementation capable of producing Response is not completely negligible.
This is not possible to avoid completely - for example, you custom filter, exception mapper or indeed the user code will inevitably create a JAX-RS Response instance which will be 'foreign' to the CXF runtime. In these cases CXF will simply copy such Responses into its own Response implementation.
I hope it will make it very easy eventually to get CXF JAX-RS up and running in the latest JBoss and Glassfish distributions, due to it becoming effectively self-contained. Some more runtime code modifications may prove to be required but IMHO we are on the right path.
It is very well understood that for a given container it makes a lot of sense to optimize around a selected JAX-RS implementation, specifically in case of JBoss and Glassfish we are talking about well-known and recognized implementations.
This effort is all about helping those users who have decided to work with CXF JAX-RS in these containers continue doing so - this is all to it really :-).