JBossWS 3.4.0.CR1 is out!

I'm happy to announce that the first candidate release of JBossWS 3.4.0 has just been released, including JBossWS-CXF (release notes) and JBossWS-Native (release notes) stacks.

This is a major step forward in the direction of JavaEE 6 compliance. While the current release supports JAXWS 2.2 (JSR 224) and most of the additions in JSR 109 v.1.3, we're targetting passing all the webservice related modules of JavaEE 6 CTS TCK with the final 3.4.0 release.

JBossWS-CXF 3.4.0.CR1 includes the recently released Apache CXF 2.3.0, which in turn comes with multiple major new features (as well as bug fixes).

Finally, the Maven plugin for the JBossWS JAXWS tools (wsconsume / wsprovide) has also been released in a new 1.0.1.GA version, which supports the SPI of the latest available 3.4.0.CR1 stacks and adds a fork mode option for effectively using the tools with JAXWS 2.2.

The Maven artifacts for all the released components are available on the JBoss public repository; please give them a try!

• JBossWS-CXF
• JBossWS-Native
• maven-jaxws-tools-plugin

com.sun.net.httpserver transport using JAXWS 2.2 HTTP SPI

In the previous post I've written about Apache CXF and JBossWS-CXF implementation of JAXWS 2.2 HTTP SPI. From a container point of view, a bit of additional coding is required for making an existing http server compliant too.

Similarly to what Jitendra Kotamraju did for Grizzly, I've just created a small project for using the JDK6 httpserver with this HTTP SPI, basically allowing any JAXWS 2.2 stack implementation to be used on top of it (not just the JAXWS RI as mentioned here). The project only runtime dependency is the JAXWS 2.2 API, so it's completely vendor agnostic (the project testsuite uses Apache CXF just for the sake of testing with a JAXWS 2.2 impl).
So, the following is now possible using any JAXWS 2.2 compliant implementation:

import com.sun.net.httpserver.HttpServer;
import javax.xml.ws.spi.http.HttpContext;
import org.jboss.ws.httpserver_httpspi.HttpServerContextFactory;
..

HttpServer server = HttpServer.create(new InetSocketAddress(8080), 0);
HttpContext context = HttpServerContextFactory.createHttpContext(server, "/ctx", "/echo");

Endpoint endpoint = Endpoint.create(new EndpointBean());
endpoint.publish(context); // Use httpserver context for publishing
server.start();
//invoke endpoint
endpoint.stop();
server.stop(0);

The binaries for the project are on JBoss' Maven repository.

Implementing JAXWS 2.2 HTTP SPI on Apache CXF

JAXWS 2.2 specification introduced a compact HTTP SPI; that defines the minimal set of required information a http server container and a JAXWS stack implementation need to share for allowing an endpoint deployment and invocation.

Previous JAXWS specification already included API for simplified endpoint deployment in a JSE environment:

Endpoint endpoint = Endpoint.create(new EndpointBean());
endpoint.publish("http://localhost:8080/jaxws-endpoint1");
//invoke endpoint...
endpoint.stop();

.. as well as a Endpoint publish(Object obj) method for allowing the JAXWS RI (only) to deploy an endpoint on top of JDK6 httpserver. However, this was not portable and different JAXWS implementation could actually support different and vendor specific http context implementations passed in that object instance in publish(Object obj). For instance, Apache CXF - despite being JAXWS 2.1 compliant - didn't have a specific implementation for the publish(Object obj) method, but just of the publish(String s) one.

With JAXWS 2.2 the specification added a Endpoint publish(HttpContext ctx) method and the other classes/interfaces defining the HTTP SPI together with the HttpContext. A JAXWS 2.2 implementation is supposed to be able to deploy an endpoint on top of any http container that also supports the JAXWS 2.2 HTTP SPI.

Thanks to a joint work of Daniel Kulp and me, the current trunk for Apache CXF now supports this JAXWS 2.2 HTTP SPI. This means you'll soon be able to perform a quick deployment and test of your endpoint using Apache CXF (or JBossWS-CXF, of course ;-)) on top of the JAXWS 2.2 compatible http server you prefer.

As a proof of that, I've added a testcase leveraging Jitendra Kotamraju's Grizzly transport bridge project for deploying on top of Grizzly http server, while still having the whole ws invocation being handled by CXF:

import javax.xml.ws.spi.http.HttpContext;
import com.sun.grizzly.http.embed.GrizzlyWebServer;
import org.jvnet.jax_ws_commons.transport.grizzly_httpspi.GrizzlyHttpContextFactory;

..

GrizzlyWebServer server = new GrizzlyWebServer(8080);
HttpContext context = GrizzlyHttpContextFactory.createHttpContext(server, "/ctx", "/echo");

Endpoint endpoint = Endpoint.create(new EndpointBean());
endpoint.publish(context); // Use grizzly HTTP context for publishing
server.start();
//invoke endpoint
endpoint.stop();
server.stop();

.. but the same would have worked with other compatible containers (just to mention one, there's a project for making Jetty compatible with the jaxws 2.2 http spi).

The whole JAXWS 2.2 support is being included in Apache CXF 2.3 and JBossWS-CXF 3.4.0 which should come out soon... in the mean time you can give the latest snapshots a try! Feedback is welcome :-)

Maven plugin for JAXWS tools

JBossWS comes with JAXWS tools for top-down and bottom-up webservice development.

Starting from today, a Maven plugin is available for easily embedding tools' invocation into your own project's pom.xml:

<build>
<plugins>
  <plugin>
    <groupId>org.jboss.ws.plugins</groupId>
    <artifactId>maven-jaxws-tools-plugin</artifactId>
    <version>1.0.0.GA</version>
    <configuration>
      <wsdls>
        <wsdl>${basedir}/test.wsdl</wsdl>
        <wsdl>${basedir}/test2.wsdl</wsdl>
      </wsdls>
      <targetPackage>foo.bar</targetPackage>
      <extension>true</extension>
    </configuration>
    <executions>
      <execution>
        <goals>
          <goal>wsconsume</goal>
        </goals>
      </execution>
    </executions>
  </plugin>
</plugins>
</build>

this makes wsconsume parse the specified wsdl files and generate java sources for the SEI, wrapper, etc. The classes are then compiled together with all the other ones in your project.

Similarly you can use wsprovide, see the example below:

<build>
<plugins>
  <plugin>
    <groupId>org.jboss.ws.plugins</groupId>
    <artifactId>maven-jaxws-tools-plugin</artifactId>
    <version>1.0.0.GA</version>
    <configuration>
      <verbose>true</verbose>
      <endpointClass>org.jboss.test.ws.plugins.tools.wsprovide.TestEndpoint</endpointClass>
      <generateWsdl>true</generateWsdl>
    </configuration>
    <executions>
      <execution>
        <goals>
          <goal>wsprovide</goal>
        </goals>
      </execution>
    </executions>
  </plugin>
</plugins>
</build>

The plugin has sensible defaults, in particular for computing the classpath to be used before invoking the tools; you just need to make sure your project declares dependencies on a jbossws stack (which you most probably already do, if you have ws endpoints there).
So it's really just a matter of declaring the plugin in the pom.xml and running ;-)
All stacks (JBossWS-Native, JBossWS-CXF, JBossWS-Metro) are supported by the plugin.
A couple of additional complete sample pom.xml files are available on the SCM, for instance take a look at this.
Enjoy!

Extending JBossWS-CXF/Metro with JAX-RPC

As you all know, Apache CXF and Glassfish Metro do not include JAX-RPC functionalities. While this is not a major issue considering users should be moving to JAX-WS for many reasons, Java EE 6 still include JAX-RPC and JBoss AS needs to provide implementation for it in order to achieve certification.

While JBossWS-Native stack includes JAX-RPC features, in the direction of further improving the JBossWS integration layer for running different WS stacks on top of our AS, we need to provide a way of supporting jaxrpc deployments when JBossWS-CXF (or JBossWS-Metro) is installed in the AS.

We've thought about possible ways of achieving this and the most viable one appeared to be leveraging the JBossWS-Native stack for providing JAXRPC functionalities, while leaving JAX-WS processing to the other installed stack. Implementing this idea basically implies being able to install multiple webservice stacks at the same time in the AS. JBossWS-Native and JBossWS-CXF/Metro need to coexist at runtime and deal with requests depending on the kind of endpoint those are meant for.

In order to deploy multiple stacks on JBoss AS, we needed to:

1. fix the deployment process: JAX-RPC deployments need to go through JBossWS-Native deployers, while JAXWS ones need to be dealt with by JBossWS-CXF deployers. There's also some kind of intersection between the two groups, as JBossWS comes with some common features that need to stay centralized (the endpoint registry, for instance);
2. ensure libs from the two deployed stacks can live together: this is quite important speaking of WS as a *lot* of things depends on Service API loading (which depends on what libraries define the current classpath).

Fixing the deployment

The deployment processing issue has been solved basically leveraging the current architecture of ws deployers in JBoss AS. JBossWS comes with a parse stage deployer (that deals with optional webservice.xml descriptor parsing) and a quite fine-grained group of real stage deployers (that performs all the analysis, setup, etc. required for the user endpoint to be properly used on the AS). The former and some of the latters are stack agnostic, meaning they don't have or do anything specific to the ws stack (Native, CXF, Metro) currently installed. Some of the real stage ws deployers, instead, are stack specific and change from stack to stack. The images below present schematically what JAX-RCP / JAX-WS deployments go through during the JBossWS deployment (of course the full deployment involves and requires other non-ws deployers to enter the game):







Adding a couple of flags (using attributes in the *-jboss-beans.xml descriptors) to stacks' deployers for marking them as being able to deal with jaxrpc/jaxws deployments, we've been able to make them run just for the deployments they're meant for. Thanks to the AS deployers' inputs/outputs and the current JBossWS deployers' modularity, there's been no need to provide implementation of new deployers, a proper combination (with the right ordering) of the already existing ones is fine. We end up with new jboss-beans.xml descriptor defining new deployer chains to be installed depending on the selected stack; jaxrpc and jaxws deployments are identified and go through the right deployers that are able to work on them.

Making stack libraries coexist

As previously mentioned, the blocking issue regarding allowing two JBossWS stack to live together stands in the factories/services specified in META-INF/services/... (Service API loading) into stacks' jars. We coped with this moving all the "offending" service configurations (i.e. those that have different values in different stacks) to descriptor only jars.

Those jars (actually only those required for jaxrpc processing) are then isolated in a specific location in application server using a separate classloader declaration (jboss-classloading.xml) and explicitly added to the classpath just for jaxrpc deployments using an additional integration deployer during the describe stage.

Basically we end up with two slightly different classpaths configured at describe stage for different deployment types. This way, when the classloader is created for the current deployment in classload stage, the proper stack is implicitly selected for dealing with it. Below you see the obtained schema:





Now... try it out!

The solution introduced above has just been included in JBossWS-CXF 3.3.0.Beta1 and JBossWS-Metro 3.3.0.Beta1 and is targeted for JBoss Application Server 6.
You just need to checkout the current JBoss AS trunk (or wait for JBoss AS 6.0.0.M3) and the tag for JBossWS-CXF/Metro 3.3.0.Beta1. Build both AS and WS stack (it's just a matter of few commands) and you're ready to go. You can play deploying jaxrpc and jaxws archives on the AS, with formers being handled by JBossWS-Native and the latters by JBossWS-CXF/Metro.
Feedback is welcome :-)

JBoss AS 6 M2 is out.. what about WS?

Just a brief message to remind JBoss AS 6 M2 has just been released. You can read about that from Brian and Rich, many interesting news come with it.

If you're wondering what changes AS 6 M2 includes in terms of web services, basically we pushed multiple JBossWS component upgrades there.

Among the others, JBossWS Native 3.2.2 improved performances while the 3.3.0.Beta2 currently in AS 6 M2 is a first step in the direction of supporting what's required for Java EE 6.

So stay tuned... and give JBoss AS 6 M2 a try, it's worth it.

JBossWS 3.2.1.GA is available

After a couple of days spent on the new website, JBossWS 3.2.1.GA release has just been announced. It features performance improvements, component upgrades, the JAXBIntro support with CXF, bug fixes, etc.

Download it now and give it a try :-)