7 Replies Latest reply on Aug 21, 2010 4:24 AM by Alessio Soldano

    JBossWS-CXF, the Endpoint API and Jetty dependency

    Alessio Soldano Master

      Hi Folks,
      as you all know, JAXWS specification includes API for publishing an endpoint in a JSE standalone environment. Here is an example http://anonsvn.jboss.org/repos/jbossws/framework/tags/jbossws-framework-3.4.0.Beta1/testsuite/test/java/org/jboss/test/ws/jaxws/samples/endpoint/EndpointTestCase.java, anyway that's basically something like:


      Endpoint endpoint = Endpoint.create(new MyEndpointBean());


      Implementing this functionality implies starting a webserver and publishing the ws endpoints on top of it.
      JBossWS-Native currently accomplish this by starting a server based on Netty and re-using the jbossws deployment aspect abstraction for the deployment.
      Apache CXF has a pluggable http transport layer that usually delegates to the Jetty server transport module (in cxf-rt-transport-http-jetty.jar). Unless differently configured, Apache CXF starts a Jetty server for deploying the provided endpoint (for instance, in a J2EE environment the current JBossWS-CXF integration installs ServletTransport factories instead of the Jetty default ones, for deploying provided endpoints to the running JBoss AS instance).
      Now, in order to avoid shipping Jetty on JBoss AS, we need to provide an alternative solution for supporting Endpoint.publish() API in JSE env when using JBossWS-CXF, see: https://jira.jboss.org/browse/JBWS-3079


      As of today, my idea would be to provide another cxf http transport layer (say cxf-rt-transport-http-netty) using JBoss Netty and implementing the API defined in cxf-rt-transport-http. Apache CXF (and hence JBossWS-CXF) should then run on that when that transport is available instead of the Jetty one (CXF already features the configuration means for automatically detecting the available components).
      What do you think?