Wednesday Mar 10, 2010

WSDL Customization Issues and Workarounds in Java EE 6 Applications in NetBeans

I've found a couple issues when using NetBeans to generate a WSDL file for an EE 6 web service, and then customizing that WSDL file. Some other users have reported them as well, so I thought I'd share them with the community.

  • When I set a new wsdlLocation attribute in the web service class, this is ignored and the default, autogenerated WSDL is used instead. It appears that GlassFish v3 doesn't recognize the wsdlLocation attribute. A bug against GlassFish has been reported (11437), there's a fix in the nightly GF builds, and the fix will be there in 3.0.1. In the meantime, it's probably worth downloading and installing the nightly GF build and registering this server in the IDE.
  • When you use NetBeans to generate the WSDL for an EE 6 JAX-WS service, generation fails because wsgen "Could not create declaration for annotation type javax.ejb.Stateless" or javax.ejb.EJB. Workaround is simply to comment out those annotations, generate WSDL, then uncomment them.

The NetBeans guys told me that the second problem is related to wsgen in JAX-WS, not an NB issue. I posted this as issue #837 in jax-ws, but the JAX-WS guys replied that this was a problem with apt, not wsgen. Their suggested workaround is to "Pass the Java EE API jar that contains @Stateless in the wsgen classpath." I don't know how this is done and am waiting to hear from the NetBeans guys, again, to find out if this is something we can do in the IDE. Also, I hope someone can explain to me what "apt" is.

UPDATE: All these issues are resolved using NB 6.9 RC, GF 3.0.1 and JDK 6 u 20.

Wednesday Apr 01, 2009

Portability and Performance in JAX-WS Clients built in NB 6.7

In NetBeans IDE 6.7, when you create a JAX-WS client, the IDE automatically creates a local copy of the WSDL and any other WSDL or schema that the WSDL references. This improves performance, because the client does not have to look up these resources on the internet. It also improves portability, since the original WSDL file and its references do not have to be available for the client to run.[Read More]

Thursday Jun 26, 2008

WSDL 2.0 vs WADL

I've just been reading this rather interesting post on WSDL and WADL via DZone. When I got to the all-too-brief discussion of WADL at the end, I realized something: after 6 years documenting web service related stuff, I still don't really know what's going on in a WSDL document. But when I look at WADL, it seems clear as day. Is this just my naive social-science-major tech writer POV, or do WS developers feel the same way?

Sunday May 18, 2008

Jersey REST 0.7, now with Spring support

Jersey REST API 0.7 contains support for the Spring framework. This post shows how to use NetBeans IDE 6.1 with REST 0.7 to create a web application where a Spring-aware servlet is exposed through both a singleton and a per-request RESTful service. [Read More]

Sunday Apr 13, 2008

WS-I Validation in NetBeans using soapUI Plugin

It's possible to perform WS-I validation of both WSDL files and SOAP messages using the soapUI plugin, available from the Update Center for NetBeans 6.1 Beta and 6.1 RC 1. soapUI is a leading tool for testig web services, developed by eviware. It's free, open-source software, with a vast feature set that includes Functional and Load Testing for Web Services, Web Services Simulation and Web Service Monitoring. In order to use the soapUI plugin for WS-I validation, you need to download and set up the Interoperability Testing Tool:
  1. Download the Java version of the Interoperability Testing Tool from the Deliverables page.
  2. Unzip the tool into the location of your choice.
  3. Create a WSI_HOME environment variable set to the location of the unzipped Interoperability Testing Tool.
  4. Open the IDE and navigate to Tools > soapUI > Preferences. Open the WS-I Settings tab and, in the Tool Location field, enter the location of the downloaded and unzipped wsi-test-tools folder. Select other options according to your preferences and click OK.
To validate WSDL files, right-click the binding node in the Web Service Tests node and select Check WS-I Compliance.

To validate SOAP messages, first monitor a SOAP request and response, as follows:

  1. Find the binding node in the Web Service Tests node and expand it to show the requests.
  2. Right-click a request and open the Request Editor, described in soapUI documentation.
  3. In the Request Editor, send a request and wait for the response.
  4. Right-click in the response window and select Check WS-I Compliance.
Each WS-I report opens in its own tab. The report is saved automatically if you set a location to save reports in the soapUI preferences. You can also save the report manually by clicking the Save icon above the body of the report.

You can see the test configuration used to generate the test report in the Config tab. SOAP message test reports also have a Log tab, which is an XML log of the request and response SOAP exchange.

Friday Mar 14, 2008

Axis2 plugin now available again! Also REST 0.6 and SOAP UI!

Those of you with an interest in NetBeans Axis2 support will be glad to hear that the Axis2 plugin is available again from the Update Center. Not that I've seen it there--I installed the latest "All" bundle of 6.1 development, and Axis2 support was already present. You'll also be glad to hear that libraries in the NetBeans project are now copied to the Lib folder of the AAR file. Milan is hoping to change the Axis2 feature to support remote server deployment. The way he'd like to do it would simplify Axis2 support in general. However, we don't know if this will be done in time for the release... REST 0.6 and SOAP UI are also now supported. More about them later, after I've had a chance to investigate further.

Tuesday Feb 26, 2008

Somewhat live blogging: Axis WS in NetBeans IDE 6.1

I have to write a tutorial for Axis WS support in the upcoming NetBeans IDE 6.1, so I got a series of instructions from Milan Kuchtiak, the engineer in the know, and got to it. Here's how it went:

Step 1: Download and install Axis 2. Well, that's easy enough, it's just a ZIP file. I see there is also a WAR file that I can download, but Step 2 is building the WAR file, so let's follow the engineer's directions and just download the zip and unzip it somewhere, say C:/ root.

Step 2: Run the build script in the Axis2/webapp directory to create axis2.war. Splendid, although there is no build script, just a build.xml. Wait, if there is a build.xml, then I can build it with ANT. Do I have ANT on my classpath? ... Nope. Have I installed ANT? ... Evidently not. So I install Jakarta ANT, put it on my PATH, and Bob's your uncle, or my uncle, or something. I wish I could write "...and Bob's your uncle" in an official tutorial. Anyway, ANT runs and I get my axis2.war file.

Step 3: Copy axis2.war to the J2EE server webapps directory. I copy it both to TOMCAT_HOME/webapps and GLASSFISH_HOME/domains/domain1/autodeploy.

Step 4: Start IDE.

Step 5: Install the Axis2 nbm plugin file. Milan sent me one as an email attachment, but the 6.1 distro I installed already had it as an available plugin, so that was easy.

Step 6: Go to Tools -> Options -> Axis2 -> Runtime and type in the Axis home directory. Easy enough.

Step 7: Still in the Axis2 Options, switch to the Deployment tab and enter the path either to the Tomcat Axis2.war or the GlassFish Axis2.war. I choose Tomcat since Axis is supposed to work a little better on that server. Milan's advise was to enter the path to the TOMCAT_HOME/webapps/axis2 directory, to which Tomcat unpacks the WAR, rather than the WAR file itself. However, I couldn't find an axis2 directory so just typed in the path to the WAR. Later I found out the significance of this absence...

Step 8: Enter the Tomcat Manager username and password. Fine, except that first I have to find out what they are. Milan said that they are in TOMCAT_HOME/conf/tomcat-users.xml, and he sent me an example of the file. It's a good thing he did, because my tomcat-users.xml is empty. I copy Milan's file into mine, and now I have Manager username "tomcat," password "tomcat."

Step 9: Create a new Java Library project. OK, I name it AxisBoldAsLove. Note to self: Do not make Jimi Hendrix references in official Sun tutorials. I create a myaxis package in the project.

Step 10: Create an empty Axis web service from Java in the project. I choose New -> Other -> Web Services -> Axis2 Service from Java and select "Empty Web Service" from the wizard. I put it in the myaxis package. Well, hurrah! I get an Axis Web Services tab in my project, with the NewAxisFromJava WS (hmmm, I should have selected a name), and the class in my source package. Terrible name.

Step 11: Implement the service class. Well heck, I can't open the Axis web service, so I guess I should change the .java class. That however already has some "Hello, World!" output specified by default. Maybe I don't need to implement anything?

Step 12: Deploy the service. I right-click the service and select Deploy... OK, I get a BUILD SUCCESSFUL message, but nothing on the Tomcat log. That doesn't seem right.

Step 13: Check that service is at http://localhost:8080/axis2/services. Er, I have a 404 error. Well, I delete my project and try everything again. Another 404! In fact, I have a GlassFish 404 error. Ah-ha, GlassFish is helpfully occupying 8080 and Tomcat is on 8084. OK, change the Axis options and the service properties and everything else I can think of to 8084. Now Deploy again. Says BUILD SUCCESSFUL again. What do I get at http://localhost:8084/axis2/services? Another 404 message! \*groan\* At least it is a Tomcat 404 and not a GlassFish 404.

OK, Milan's gone but Lukas Jungmann listens to my woes. We go through my project. And here's the nub: I should have copied axis2.war to the Catalina base, which is in Documents and Settings/Jeff/.netbeans, not to TOMCAT_HOME. Well, bloody hell, I copy it to CATALINA_BASE.

Still a 404 error! Lukas scries my log and sees that when I redeploy the WAR file, I'm still redeploying the one in TOMCAT_HOME. So we look at Tools -> Options -> Axis2, and sure enough, it's still pointing to the TOMCAT_HOME WAR file. So I change that, redeploy the service and generate a WSDL file.

Success at last! Everything is where it's supposed to be, and a JAX-WS client can be created based on the WSDL file.

Well, dear reader, by the time you see my tutorial this process should be simplified somewhat. Step 6 is already obsolete, because Milan has received permission to include the Axis libraries directly in our plugin. I'll try to play around with the service code a bit to see if I can make it do anything interesting, but really there's not much to it. All the operations appear to take place in a standard Java class, and that class is then exposed as an Axis web service. To change the operations, you change the java class and these changes are automatically reflected in the Axis web service. Milan's added subnode display to the web service in the project, so you can watch the operations get added to the web service in real time! After changing the service, you of course have to redeploy it, and then whoever is running the client has to refresh it.

Thursday Jan 31, 2008

Community Contributions

My team members are starting to link relevant community contributions from our documentation index pages. If you look at the web services documentation home page, you'll see the new category Community Contributions with the very first contribution, Kristian Rink's Web Services with NetBeans (for Eclipse users). This is the first part of what I hope will be a series about how much better it is to develop web services with our IDE instead of someone else's. Anyway, if you think of any cool demonstrations of developing web services on NetBeans IDE, do please post to

I'm a technical writer for NetBeans, covering web service support.


« June 2016