| JAX-RS : Deployment |
This page provides the tips on how to deploy CXF JAX-RS applications packaged as WAR archives or OSGI bundles into Java EE application servers and OSGI containers.
Please see CXF SpringBoot documenation.
Please see JAX-RS Spring Boot and JAX-RS Spring Boot Scan demos.
1. System "org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH"
and "org.apache.catalina.connector.CoyoteAdapter.ALLOW_BACKSLASH" properties may have to be set to "true" to support URIs containing encoded forward or backward slashes.
2. When using mod_jk - ensure that the JkOptions setting has +ForwardURICompatUnparsed set.
3. Windows: upgrade isapi_redirect.dll if you see URI containing encoded spaces being decoded by Tomcat.
Verified with Glassfish Server Open Source Edition 3.1.1
1. Make sure a cxf-rt-transport-http-jetty dependency is excluded during the war build
2. If a custom JAX-RS Application is included then
use a CXFNonSpringJaxrsServlet to reference the Application implementation class and either
2.1 Disable the Jersey scanning the custom web applications. Setting the following system property may help:
"-Dcom.sun.enterprise.overrideablejavaxpackages=javax.ws.rs,javax.ws.rs.core,javax.ws.rs.ext"
2.2 Remove jersey-gf-server.jar from $GLASSFISH_HOME/glassfish/modules
Verified with JBoss AS 7.1.0.CR1b
1. If a custom JAX-RS Application is included then
use a CXFNonSpringJaxrsServlet to reference the Application implementation class and either
1.1 Disable the RestEasy scanning the custom web applications (TODO: specify how this actually can be done)
1.2 Modify $JBOSS_HOME/standalone/configuration/standalone.xml by commenting out a "org.jboss.as.jaxrs" extension and a "urn:jboss:domain:jaxrs:1.0" sybsystem.
2. JBoss does not support URI path slashes by default: http://securitytracker.com/id/1018110
Verified with WebLogic Server 12c (12.1.1)
If you configure CXFServlet to redirect to custom JSP pages then you need to add the following declaration to web.xml:
<servlet> <servlet-name>jsp</servlet-name> <servlet-class>weblogic.servlet.JSPServlet</servlet-class> </servlet> |
Add a "prefer-application-packages" block in weblogic.xml, including the package "javax.ws.rs.*", for CXF RuntimeDelegate be visible after the application has been redeployed
WebLogic requires the following update to the proprietary deployment descriptor weblogic.xml:
<container-descriptor> <!-- SNIP --> <prefer-web-inf-classes>true</prefer-web-inf-classes> </container-descriptor> |
This instructs WebLogic's classloaders to look FIRST in the JARS from the application's WEB-INF/lib directory for Service Provider Implementations (in this case, to find META-INF/services/javax.xml.stream.XMLInputFactory in the Woodstox JAR) rather than to the system classloader.
Please see this thread for more information.
It was reported that downgrading a web-app descriptor version in web.xml can help disable the native (Jersey) scanning:
<!-- From: -->
<web-app version="3.0" xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_3_0.xsd">
</web-app>
<!-- To: -->
<web-app version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
</web-app> |
It was reported if myfaces-shared-impl-4.1.0.jar is shipped in a web application lib folder then removing it helps, with the following descriptor being effective:
<weblogic-web-app>
<context-root>/emessaging</context-root>
<container-descriptor>
<prefer-web-inf-classes>false</prefer-web-inf-classes>
<prefer-application-packages>
<package-name>javax.faces.*</package-name>
</prefer-application-packages>
</container-descriptor>
</weblogic-web-app> |
Please see the following email message.
It has been reported CXF RuntimeDelegate may not be visible after the application has been redeployed in Geronimo. Most likely Geronimo needs to be configured similar to the way WebLogic has to to resolve the same issue (please see the relevant section above), TODO: update the section once we know the actual details.