1 2 3 Previous Next


37 posts

 One of the features introduced in JAX-WS 2.2.2 RI, integrated in Glassfish 3.1 MS4, is the clientjar option to ease client-side web services programming. 

As you know, the standard client-side programming with JAX-WS RI involves running wsimport on the service wsdl, which generates the necessary classes needed for web service invocation. But all the information required by the JAX-WS runtime is not captured in the SEI or the WebServiceClient through standard web service annotations defined in the JAX-WS/JSR-181 spec. JAX-WS RI also saves the location of the wsdl in the generated classes so that it can retrieve the additional metadata of the service. This ability to fetch metadata at runtime is useful when there are some changes in endpoint policy or some compatible changes made in the service definition, the clients need not have to be regenerated. But, this  requires an additional connection just to access the metadata each time a service instance is created which can be costly at times. To workaround this, One could download the wsdl and make it accessible to the client runtime via jax-ws-catalog or other means. But, its painful to download all the wsdls and schema associated with the service and generate  jax-ws catalog to use the local files. 

In JAX-WS 2.2.2 RI, we are introducing -clientjar option for wsimport, which automatically downloads the wsdl and schema and packages all the generated client-side artifacts into a jar file. Just invoke wsimport as follows "wsimport -clientjar wsclient.jar http://example.com/service/hello?WSDL". So, invoking the web service from your program is as easy as placing the generated client jar in the classpath. A sample "wsimport_clientjar" is bundled in JAX-WS RI/ Metro 2.0 nightly bundles. Give it a try.

As you know, JAX-WS RI  has long supported publishing of asynchronous web services through the use of  RI specific AsyncProvider api. There have been requeststo add the asynchronous support for the SEI based web services (the more common developer paradigm) and standardize it, I hope it would have a place in the future revision of the JAX-WS Spec. But the current AsyncProvider api can serve the purpose for advanced use cases with more control over the SOAP messages. Though this is an important ingredient for making the web services asynchronous, its usefulness could be leveraged only with the support of the underlying transport/communication framework. As Kohsuke mentioned in his blog, JBI has implemented a custom HTTP binding component over Grizzly that has capability to process requests in asynchronous manner.  But, like most other web frameworks, normal JAX-WS web service endpoints are published as servlets running in the web container. The SOAP messages get processed by the jax-ws runtime via servlet request/response. Until servlet 2.5, the servlet request processing is synchronous, i.e if the web service (underlying servlet) is waiting for a resource or event to happen, a container thread has to wait until the request is processed and response is committed. This would result into wasting precious container resources while the thread is blocked. This would be more apparent when you have thousands of concurrent requests to long running/slow running operations, where each thread servicing the request is blocked . Though the jax-ws runtime is capable of  asynchronous processing of requests,  it is limited by the blocking invocation model of the underlying servlet.

It's no longer the case as JAX-WS 2.2.2 RI makes use of the asynchronous servlet capabilities introduced in Servlet 3.0. With async programming model, the container thread is relinquished while the request is processed asynchronously, and when processing is done or a timeout occurs, the response can be sent or the request can dispatched back to the container. To make this happen, first the servlet needs to be declared as async-supported in web.xml or through @WebServlet annotation. For more details on asynchronous servlet programming model, refer to this techtip. JAX-WS runtime takes advantage of this asynchronous servlet layer( a transport layer interns of jax-ws) and the already existing AsyncProvider API to provide better scalability and efficient use of server resources. 

This asynchronous servlet transport feature is introduced in Glassfish V3.1 MS3 and you can find a working "asyncservice" sample in latest JAX-WS RI 2.2.2 nightly build or latest Metro 2.1 promoted build to try on any Servlet 3.0 supported container. I added a "asyncservice" sample demonstrating the usage of this feature.A quick recap of the how web service implementation looks,

public class AsyncProviderImpl implements AsyncProvider<Source> {    
    public void invoke(Source source, AsyncProviderCallback cbak, WebServiceContext ctxt) {
        //queue the request for long running operation
        //return, response is sent via cbak.send(response) or cbak.sendError(throwable) in a separate thread
Here, the request is queued or processed in a separate thread releasing the container thread. The response is sent by calling the AsyncProviderCallback.send(response) or AsyncProviderCallback.sendError(throwable). As a second step, to make it truly asynchronous with the servlet web service endpoints, you need to mark the JAXWSServlet as async capable by specifying  <async-supported> true</async-supported>. As I blogged earlier, web.xml configuration is optional now, in that case, JAX-WS by default registers the servlet as async supported. If the response is not sent in a expected time interval, timeout occurs and JAX-WS runtime sends an error response. Currently, the timeout for the web service relies on the servlet implementation default. In future, we may provide an explicit configuration for the timeout.

Though this feature helps in better scalability on the server-side, the HTTP connection is still open in the background and the client  might be still waiting for the response because HTTP is a request/response protocol. One could use the support of the other WS-* specifications like Non-anonymous Addressing feature for addressable clients or WS-MakeConnection for non-addressable clients to make it asynchronous end-to-end. I will write about doing that with Metro in a future blog.

With JAX-WS 2.2.2 RI /Metro 2.1, Web Services deployment using RI deployment model has been made even simpler by making the web services configuration in web.xml optional.

 As you know, JAX-WS RI supports two deployment models to publish web services, one using JSR-109 deployment model and the other JAX-WS RI specific deployment model. In JSR-109 deployment model, a web service can be specified in web.xml as a servlet class and any additional configuration is specified in webservices.xml. JSR-109 supported container would then publish the web service using the servlet framework. With Java EE5, configuration of web.xml is made optional with the use of annotations. Though this is made quite simple, it works only on Java EE Containers supporting JSR-109.  To support web service deployment on plain servlet container like Tomcat, We use JAX-WS RI deployment model, where web service configuration is specified in sun-jaxws.xml and explicit declaration of RI specific servlet classes in web.xml. So, to deploy JAX-WS web services on a Servlet 2.4 Container, one has to at the minimal configure web.xml and sun-jaxws.xml. Here is sample web.xml configuration for JAX-WS web service.

 Old configurtation in web.xml:

<web-app version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee"


         xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">







        <description>JAX-WS endpoint - fromwsdl</description>















Most of the time such configuration is auto-generated by IDEs like Netbeans and is unnecessary. With the introduction of dynamic registration of Servlets feature in Servlet 3.0, this whole thing can be made optional. With JAX-WS 2.2.2 RI, JAX-WS Runtime utilizes the Servlet 3.0 capabilities to dynamically register a servlet for each web service endpoint specified in sun-jaxws.xml. This should work in any Servlet 3.0 container like GlassFish V3, Tomcat 7 etc. This simplified deployment feature is introduced in GlassFish 3.1 MS3 and you can find a working sample from Metro 2.1 latest promoted build  here.  The dynamically registered JAX-WS servlet uses default settings in most cases and if you need to do advanced configuration like security, you can still  specify in web.xml as you used to earlier.

 Of course, with the use of jax-ws annotations, even configuration sun-jaxws.xml can be made optional making it completely descriptor free, but that requires specifying a default url-pattern like in JSR-109 or custom pattern like in Jersey REST services, in the JAX-WS specification. As it is, such descriptor free deployment is already supported by 109 implementation from Glassfish V2. This definitely is a step towards that goal and one less configuration file to worry about. 

 You can download the optional_webxml sample from JAX-WS RI 2.2.2 nightly build or Metro 2.2.1 promoted build and let us know your feedback.


Rant on Ant 1.7.1 Blog

Posted by ramapulavarthi Mar 29, 2010

If you are using Ant 1.7.1 for developing Web Services with JAX-WS/JAXB, I suggest you to move to the latest version Ant 1.8.0.

JAXB/JAX-WS rely on package level runtime annotations for lot of things. For ex: JAXB relies on the @XmlSchema annotation in package-info.java and uses it for binding Java data types to XML schema types. You might be puzzled to see that the mappings are not as expected. I wasted almost half a day trying to figure out if there was some regression in JAX-WS/JAXB as I was suspecting Ant the least. A bug in Ant 1.7.1 javac ant task, makes it not compile package-info.java. This is a serious regression and the impact is not directly obvious until you see the behavior change in this case. The issue is resolved in Ant 1.8.0 and I encourage all JAXB/Metro users to use Ant 1.8.0 for development.

Jitu and I are going to speak at JavaOne 2009 on JAX-WS 2.2. The BOF is on Wednesday, June 03 7:45 PM - 8:35 PM. We will be talking about the new features in JAX-WS 2.2. If you use JAX-WS, Metro, drop by the Glassfish booth or at BOF to say hi and ask any questions you might have. Hope to see you all there.  
We are trying our best to keep the JDK up to date with latest JAX-WS RI. The recently released JDK 6 Update release 14 has JAX-WS 2.1.6 RI along with JAXB 2.1.10 RI. You can find more about the changes that went in to the release can be seen at JAX-WS 2.1.6 change log and JAXB 2.1.10 change log. I hope the JAX-WS users find this helpful.  

JAX-WS Maven2 plugin 1.12 is released which has some bug fixes related to configuring the wsimport/wsgen options and minor usability issue. JAX-WS maven plugin 1.12 depends on recently released JAX-WS RI 2.1.7. Along with other changes in JAX-WS RI 2.1.7, For maven users it has one important bug fix related to the dependency on the woodstox.

Just a recap on the previous 1.11 release, If you have n't noticed, In 1.11 wsimport goal default behavior is changed to not compile the generated sources. This was fixed as JAX-WS-COMMONS-25.

Fixes in 1.12 release are 
  • JAX-WS-COMMONS-36: wsgen extension option is not working with the maven plugin.
  • JAX-WS-683: Confusing Warning "Nothing to do, no WSDL found!" with wsimport goal.


You can find more about the plugin usage at jax-ws commons project. Do let us know if you see any issues with using the maven plugin.

If you trying to use JAX-WS 2.2 on top of JDK 6, you run into classloading problems. Resonating with the problems we had with using JAX-WS 2.1 on JDK 6 FCS?, Dejavu !!!.

As you guessed, JDK 6 (U4 and later) has JAX-WS implementation with JAX-WS 2.1 API. If you try to use JAX-WS 2.2, the runtime always picks up the JAX-WS API from bootclasloader and will not see JAX-WS 2.2 API in your classpath. Well, the solution is the same, i.e, using the endorsed overriding mechanism. This has been documented and discussed before.

But how do you configure for Web Services running on Tomcat 6 using JDK 6. Its easy with Tomcat 5.5, you just need to copy jaxws-api.jar and jaxb-api.jar into $TOMCAT_HOME/common/endorsed directory. But there are some changes in classloading in Tomcat 6.x and there is no documentation on the default endorsed directory.

Here it is, you have to create endorsed directory in $TOMCAT_HOME and Copy jax-ws.api.jar and jaxb-api.jar from JAX-WS (webservices-api.jar in case of Metro) to $TOMCAT_HOME/endorsed. You might also find my other blog on running JAX-WS samples on Tomcat 6.x useful.

I am putting here one of the problems one would see when using JAX-WS 2.2 features without endorsed mechanism. For ex, if you are using AddressingFeature.Responses added in JAX-WS 2.2 API, you would get
SEVERE: WSSERVLET11: failed to parse runtime descriptor: java.lang.NoSuchMethodError: javax.xml.ws.soap.Addressing.responses()Ljavax/xml/ws/soap/AddressingFeature$Responses; java.lang.NoSuchMethodError: javax.xml.ws.soap.Addressing.responses()Ljavax/xml/ws/soap/AddressingFeature$Responses;

Follow the above tip to configure the endorsed directory and it should work.

Tomcat 6

In my previous blog, I mentioned about the recent developments with JAX-WS 2.2. If you want to get your hands on latest JAX-WS 2.2, Try downloading the JAX-W 2.2 nightly builds from here.

Metro 2.0 includes JAX-WS 2.2 and JAXB 2.2. Metro 2.0 nightly builds are available here

We will soon try to push out the JAX-WS 2.2 snaphots to Maven.

Java.net Maven Repo Update: If you are experiencing problems accessing the JAX-WS/JAXB artifacts from java.net Maven repository, there have been some changes to java.net Maven repository. Developers who push to java.net Maven repository should be aware of changes made to java.net Maven repository, See Kohsuke's announcement for details. As an user, if you are usinghttps://maven2-repository.dev.java.net/nonav/repositoryorhttps://maven-repository.dev.java.net/nonav/repository, you should change it to usehttp://download.java.net/maven/2/ andhttp://download.java.net/maven/1/respectively.

Its been a long time I blogged. You might be wondering what we are up to with JAX-WS RI lately. We are busy implementing the JAX-WS 2.2 RI.

Jitu, Spec lead for JSR 224 has already sent the proposals on JAX-WS 2.2 features. JAX-WS 2.2 is mainly aimed to add the missing support for WS-Addressing 1.0 - Metadata specification in the earlier release. This requires WS-Policy 1.5 support in JAX-WS to understand the WS-Addressing Metadata defined policy assertions. For WS-Policy 1.5 support, JAX-WS is using the Policy implementation from WSIT ( Policy project on java.net). We have integrated the Policy libraries in JAX-WS 2.2 and with this JAX-WS can understand/generate policies as defined in Web Services Policy 1.5 -Attachment.

JAX-WS 2.2 will be part of Metro 2.0. The roadmap for Metro 2.0 can be found here and more details on the features targeted for Metro 2.0 are on Metro One Pagers. Some of the support for WS-Addressing Metadata is already implemented. The development for JAX-WS 2.2 is happening onjaxws22 branch of jax-ws-sources/jaxws-ri repository. Since JDK 6 already has JAX-WS 2.1 API, there are some possible classloading issues if you are using JAX-WS 2.2 on JDK 6. You have to resort to endorsed mechanism or use JDK 5 for now. We are working on alleviating this problem going forward.

I am going to write in detail about the features for WS-Addressing and other enhancements in JAX-WS 2.2 in a later blog. The nightlies will be out soon once the 2.2 API are finalized.

Regarding the JAX-WS 2.1 implementation in JDK 6, We are working on syncing up JDK 6 with latest JAX-WS 2.1.X. You should see it in a future JDK 6 feature update release.

Netbeans 6.5 is recently released. Along with tons of new features, it has some enhancements for Web Services development.

The foremost is that with Netbeans 6.5, you can easily develop Web Services applications and deploy on to Glassfish V3. There are are other features like configuring WS-Addressing, and exposing a SOAP based Web service as REST service through GUI caught my attention.

Coming to configuring WS-Addressing, You can easily configure by editing the Web Service attributes and checking the box for Addressing as shown in the following picture.


Previously, it was enabled if it required by other option like Reliable Message Delivery. This feature lets you configure your Web Service to use WS-Addressing without other technologies. Doing this automatically generates WSIT configuration file with the right policies to enable WS-Addressing as shown below.

    <wsp:Policy wsu:Id="NewWebServicePortBindingPolicy">
                <wsaw:UsingAddressing xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl" wsp:Optional="true"/>

Its currently generating <wsaw:UsingAddressing> assertion, in future this would generate <wsam:Addressing> when Metro supports WS-Addressing 1.0 Metadata specification. Of course, you can still configure in other ways by using the annotation @javax.xml.ws.Addressing on the endpoint implementation or programmatic configuration using AddressingFeature()

Among other things in Netbeans 6.5, you can expose a SOAP based Web Service as a Restful Service. Right click on the Web Service, select Generate SOAP-over-HTTP wrapper option. It generates a Rest resource.


Wow,thats easy!!!.
Download Netbeans 6.5 and give it a try.

The problem: JAX-WS 2.1 API in Maven Central repository and Java.net Maven repository are not in sync. Based on the repository you configured in your project, you may get different flavors of the API. This often results in to compilation errors using JAX-WS Maven plugin. for example, you may get "Caused by: java.lang.NoClassDefFoundError: javax/jws/WebService ..."

Some background: Java.net has two maven repositories, Java.net Maven 1 (M1) and Java.net Maven 2( M2). As you know, JAX-WS RI's artifacts and dependencies are scattered in both of these repositories. [ There have been some requests to post everything into java.net M2 repository, and we are working on that. We are just continuing pushing to the M1 repo just so that people using that repo would still find the updated versions of JAX-WS. We are pushing all the new JAX-WS extensions to M2 repo. As mentioned, we are working on syncing both the repos moving forward.]

While we were working on the JAX-WS 2.1 API, it was mistakenly pushed multiple times as 2.1 instead of as 2.1-SNAPSHOT with an automated job. In the meanwhile, some folks synced up the Maven Central repository with java.net M1. When the JAX-WS 2.1 API is final, the Maven Central repository is not synced up again to reflect the changes in Java.net M1 repo. So, we have different flavors of JAX-WS 2.1 API in Maven Central with incorrect dependencies and Java.net M1 with the correct dependencies under the same groupId and artifactId.

Then some folks have realized about the discrepancy and tried to fix the problem in Maven central repo. Since they could n't sync up the updated version 2.1 again, they bumped up the version to 2.1-1to reflect the updated JAX-WS 2.1 API on java.net M1 as discussedhere. But JAX-WS 2.1.X RI and its associated maven plugin still depend on 2.1 version, so the jax-ws api you get still depends on which repo you are fetching from. We could have updated our RI to use the 2.1-1 to fix it and end of the problem, right? Not exactly. JAX-WS 2.1 API depends on revised version of JSR 181 API (which we pushed on to Java.net M1 as "jsr181-api 1.0-MR1"). Seems there is a rule that all the artifacts in Maven central should have its dependecies also in Maven central. Since "jsr181-api 1.0-MR1" is not there in Maven central, When the Maven Central was updated with JAX-WS 2.1-1 version of API, they modified the dependencies to use "jsr181-api 1.0". For all your JAX-WS dependent apps to work correctly, we cannot use "jsr181-api 1.0", there have been lot of changes that went in to JSR 181 Maintenance release to sync up with JAX-WS 2.0. So, We cannot use JAX-WS API 2.1-1 in Maven central. These different versions confuses lots of JAX-WS users as we can see from the maven related discussions in the Metro forum.

Workaround: If you already have a version of JAX-WS API 2.1 checked out from Maven Central, clean your local repo and use Java.net Maven repos to get all the JAX-WS artifacts. Add the Java.net repositories to your project, so that Maven looks in these repos before it gets them from Maven central.

            <name>Java.net Repository for Maven 1</name>
            <name>Java.net Repository for Maven 2</name>

Fix the Mess: So, we have messed up versions of JAX-WS API everywhere, what do we do now. The solution would be, if BEA pushes the updated jsr181-api into Maven Central repo, We can modify JAX-WS API to use it and bump up the version to 2.1-2 (following the convention started at Maven Central) and push it to java.net M1 and Maven central. But I am little hesitant with this versioning convention, as there is no JAX-WS 2.1.2 specification and an api with 2.1-2 associated with Spec version 2.1 would be confusing. The future JAX-WS Specification would be JAX-WS 2.2 if it goes for another maintenence. Then we would have to wait until JAX-WS 2.2 comes out to fix this. I guess going with 2.1-2 is better than living with these broken dependencies. What do you prefer?

I hope we fix this soon.

JAX-WS relies on JAXB for data binding. When you invoke Wsimport Tool on a wsdl, It in-turn calls XJC tool in JAXB RI to generate the beans used by the JAX-WS runtime. Occasionally, You may need to pass XJC specific command line options through wsimport tool to customize the databinding. You can do it easily with Wsimport. This feature has been there from JAX-WS 2.1 and hopefully this blog explains the common questions on its usage.

If you are using XJC directly, you could pass those options on the command-line for XJC tool or as nested <arg> elements incase of XJC ant task. For example, if you want to disable the strict schema correctness checking while compiling the schema.

You can use

/path/to/jaxb/bin/xjc.sh -nv myschema.xsd
or in ant like 
<xjc schema="src/myschema.xsd" destdir="src">
    <arg value="-nv" />
More about XJC command-line options can be found here.

But, if you want to customize the XJC behavior using wsimport tool, you can use on of the following method. For the command-line wsimport tool, you can pass xjc options using -Bprefix. For passing the similar xjc option as described above, you can use

/path/to/jaxws/bin/wsimport.sh -B-nv myservice.wsdl
Notice that XJC options are differentiated from wsimport options by prepending "-B" to the option.

The same through wsimport ant task can be done using the nested <xjcarg> element which follows the same command-line argument mechanism in Ant.

<wsimport wsdl="myservice.wsdl">
  <xjcarg value="-nv"/>

This mechanism can also be useful for using XJC plugins through wsimport as explained in Kohsuke's blog. Similarly, you can pass episode files created through previous jaxb compilation to Wsimport ant task using the nested <xjcarg> element.


Hudson@JavaOne Blog

Posted by ramapulavarthi May 15, 2008

Kohsuke and I talked about "Improving the Engineering Process Through Automation by Hudson" at JavaOne last week. Kohsuke talked about Continous Integration, best practices with larger deployments of Hudson and extensibility features in Hudson. I showed the demo of some of the features of Hudson.

The demo has two parts. In the first part, the focus was on the ease of installation and using Hudson. We showed that Hudson can be installed by doing "java -jar hudson.war" and it needs no container setup or database configuration to get started. Later showed the WEB UI for manging hudson and creating new jobs. The configuration in Hudson is very intuitive with inline help for all the configuration parameters and on the fly error checking. This is very handy where we don't have to wait until the build fails to realize its because of a silly typo.

First, I created a "FreeStyle Job" which checks out sources from a subversion repository and runs ant to build the project and run some tests. Later configured the job to archive the artifacts generated by that project and report Javadoc and Junit results. The Junit reporting feature in Hudson is very nice that it gives additinal information than it is there in your Junit reports. It offers easier navigation to reports of tests across different builds and keeps track of the age of test failures and plots trends with various builds etc.

Configuring the build to run periodically is very easy with hudson. It uses Cron-like syntax to set it to run whenever you want it. It can also monitor the SCM changes so that it can run automatically when ever somebody makes change to the sources instead of running periodically. This was shown in the demo by configuring to poll the subversion every minute for changes. I set up a mail server on my macbook to show that Hudson can send email notifications of the build status.

Later, I showed the newly introduced Maven2 project. Hudson has nice integration with Maven2 where it parses the POMs in your project and monitors the goals you run to execute some routine housekeeping you do with normal hudson job. For example, when you run "test" phase , it automatically records the Junit Reports and archives the artifacts. With this Maven2 Project feature, you need to do very little configuration to setup the job like hooking up the sources and invoking Maven to execute some goals.

In the second part, We showed the distributed build setup and Multi-Configuration Job(Matrix job). Adding slaves to the Master Hudson requires running hudson slave agent on the slave computer. It is as easy as clicking a Java Web Start link from the slave computer thats being hooked up. Of course, you can use other mechanisms like SSH to run the slave agent on the slave computer. Later we showed creating Multi- Configuration Job where the project tests are run in different configurations. The Multi Configuration job can be very handy when you need to build something for different platforms or run tests with different configurations (like different containers, different JDKs, different databases etc.). You don't need to create a separate job for each configuration. Just create a Multiconfiguration job to instruct hudson to run in all the combinations of the parameters in parallel. Hudson not only runs the jobs in all the configurations in parallel but also aggregates the artifacts and reports from all the builds and shows in a nice matrix for easier comprehension. We did n't get enough time to show this feature completely in the session.

The response from the audience was great and they liked the features of Hudson and the value it brings in. I am planning to create some screencasts of these demos and some other useful features like build promotion and put it on Hudson wiki. Go get Hudson and give it a try. Another important thing is that when you try Hudson, also look at the growing list of Hudson Plugins to work with various build systems, SCMs, notification mechanisms etc that complement the common core features in Hudson.

You can find javac compilation issue with classes in javax.xml.ws.wsaddressing package in my previous blog "A little update for JAX-WS 2.1 users with JDK 6 Update 4 and Update 5" The corresponding bug 6672868is fixed in JDK 6 update 6. The fix should be available in Open JDK 6 as well. So, you don't have to use the compiler switches or workarounds as mentioned in my previous blog to make it work :)  

Filter Blog

By date: