Ready for JBoss AS 6... and then?

Community members watching recent JBossWS subversion repository activity might have noticed that we've been having two open 3.4.x branches for quite some time. What's the meaning of that?

From one of the branches, JBossWS 3.4.0 was released just last week and had many new features, available for already released AS containers (including AS 6 CR1 and AS 5.1.0.GA). That came with JAXWS 2.2, JSR 109 v1.3, etc. - you can read all the details on my previous blog post.

On the other side, the efforts above on webservices technologies are of course meant for eventually satisfying the general JBoss Application Server EE6 certification needs. Because of that, a lot of work is being done on JBoss AS 6 trunk. In particular we had to review part of the internal webservice integration layer with the AS, to accommodate other components requirements and changes. This all happened on the branches for JBossWS 3.4.1, which has finally been released on yesterday and is ready for being the final ws stack of JBoss Application Server 6.
So 3.4.1 basically introduces just few minor additions over 3.4.0 for the end users (see the release notes [1][2]), but includes some internal changes that are really relevant for AS 6. Besides that, we verified the testsuite with IPv6 addresses ;-)
The only supported target container for 3.4.1 is the current JBoss AS 6.0.0-SNAPSHOT, which (hopefully) will soon turn into AS 6 final.


The future: JBossWS 4 and JBoss AS 7

So, what are we going to work on once we're back from X-mas time? ;-)
You might have heard on the November 17th JBoss Community Asylum that AS 7 development is really on... well, it's time for the WS team to focus on it.
Major new features and changes are coming with JBossWS 4... take a look at JIRA, the dev forum and feel free to comment/participate :-)

JBossWS 3.4.0 has landed!

It's been almost two months after 3.4.0.CR1 has been released... but finally JBossWS 3.4.0 is out! I'm happy to announce that both JBossWS-CXF and JBossWS-Native final versions have been released and are available for download. The supported target containers are JBoss AS 5.0.1, 5.1.0 and 6.0.0.CR1.

This release is the result of the hard work since the beginning of 2010 on supporting the JAXWS 2.2 and JSR 109 v.1.3 changes required for JavaEE 6. Part of the work actually came through collaboration with the Apache CXF community; as a matter of fact the Apache CXF 2.3 series (included in JBossWS-CXF 3.4.0) features JAXWS 2.2 compliant functionalities.

JBossWS-CXF 3.4.0 is meant for being the stack providing webservices functionalities to JBoss AS 6, which in turns aims at JavaEE 6 compliance. We're going to cut another minor release for dealing with last minute integration issues just before AS goes final, but from a feature point of view 3.4.0 already has all you need for JavaEE 6 webservices development.

Besides that, JBossWS-CXF 3.4.0 comes with all the new features and many bug fixes of Apache CXF 2.3.0 and 2.3.1, part of which were directly contributed by our team members.
Take a look at the release notes for the full list of improvements.
Of course, the Maven artifacts for all the released components are also available on the JBoss public repository; please give 3.4.0 a try!

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.