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

    JBossWS-CXF, the Endpoint API and Jetty dependency

    asoldano

      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());
      endpoint.publish(publishURL);
      ...
      endpoint.stop();

       

      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?

        • 1. Re: JBossWS-CXF, the Endpoint API and Jetty dependency
          ropalka

          My CXF architecture knowledge is so minimal that I can't talk in details.

          However what you wrote here sounds reasonable to me.

          There's only one thing I'm really affraid of. We (JBoss) are still not sure,

          what is the AS future, Netty or XNIO or both, see last comment on TAG-31

          From last comment I see XNIO is for AS 7, but this needs to be

          identified/discussed first (with David, Trustin & other

          responsible people) before we'll take final decission if to use XNIO or Netty or whatever.

          • 2. Re: JBossWS-CXF, the Endpoint API and Jetty dependency
            dmlloyd

            You could just use com.sun.httpserver (it's GPL) like the JDK one does, and save yourself a dependency on most platforms, if that's the purpose of what you're doing.

            • 3. Re: JBossWS-CXF, the Endpoint API and Jetty dependency
              ropalka

              David comes with another question and it makes perfect sense to me.

               

              <dmlloyd> honestly it's a bit surprising since the JDK includes the built-in JAX-WS
              <dmlloyd> is there a reason a user wouldn't just use that in an SE environment?
              <opalka> dmlloyd, We didn't test it using JDK client
              <opalka> dmlloyd, But your question sounds reasonable
              <opalka> dmlloyd, I'm giving it for discussion
              <opalka> dmlloyd, One of the reasons many JAX-WS implementations provide its own clients is because of WS-* they (claim) to implement
              <opalka> dmlloyd, but for TCK6 it makes sense anyway, because we don't use stack specific features there.
              <opalka> dmlloyd, I asked the same question Alessio few days ago why not TCK6 certify it using JDK provided client

               

              Let's discuss this last sentence folks Objections?

              • 4. Re: JBossWS-CXF, the Endpoint API and Jetty dependency
                ropalka

                It's not possible to use JDK6 jaxws client, because JDK6.x provides JAX-WS 2.1

                and TCK6 requires JAX-WS 2.2

                • 5. Re: JBossWS-CXF, the Endpoint API and Jetty dependency
                  asoldano

                  David Lloyd wrote:

                   

                  You could just use com.sun.httpserver (it's GPL) like the JDK one does, and save yourself a dependency on most platforms, if that's the purpose of what you're doing.

                  Right, good point, forgot about that. This would also reduce the dependencies of Apache CXF itself.

                  The point is, is this available in all platform we "support" ? (and/or certify, from a product point of view)

                  • 6. Re: JBossWS-CXF, the Endpoint API and Jetty dependency
                    asoldano

                    Richard Opalka wrote:

                     

                    It's not possible to use JDK6 jaxws client, because JDK6.x provides JAX-WS 2.1

                    and TCK6 requires JAX-WS 2.2

                    yes... but generally speaking, like other vendors, we're providing our own stack, including client side stuff (also for implementing features that are not covered by jsr specs) and that's what we need to certify.

                    • 7. Re: JBossWS-CXF, the Endpoint API and Jetty dependency
                      asoldano

                      Fort the records, I've just committed a initial implementation of a new transport module for jbossws-cxf integration based on jdk6 httpserver.

                      See http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossws?view=revision&revision=12824