Latest Activity

Using Eclipse to debug CXF- or Metro-based SOAP calls

Glen Mazza - Tue, 07/26/2011 - 13:00

This tutorial shows how to use Eclipse to debug/trace SOAP requests and responses, either CXF or Metro-based, from both the web service and SOAP client perspective. We'll primarily be covering Mavenized projects using the DoubleIt tutorial web service provider (WSP) and SOAP client as an example.

First, if you're trying to track down a bug in your web service calls, before resorting to IDE debugging there are two simpler solutions that might locate the problem:

  • Activate (or increase the level of) logging for the WSP and/or SOAP client. For CXF, as shown on the project debugging page, this can be done by attaching logging interceptors to the WSP and/or SOAP client and configuring a logging properties file. The client pom.xml in the WSDL-first tutorial has a placeholder to indicate your logging properties file when activating the SOAP client. Metro uses a different configuration mechanism--see the client pom.xml as well as their logging page for more information.

    Note: To view message-layer encrypted messages before encryption or after decryption (i.e., to see human-readable messages), configure these special logging settings for Metro. For CXF, setting the java.util.logging level to FINE or the Log4J level to DEBUG should allow you see pre-encrypted/decrypted messages from the WSS4J library that CXF uses for this process.

  • Use Wireshark to trace SOAP requests and responses. Wireshark allows you to observe the contents of network traffic messages. In addition to standalone usage, Wireshark can be run while doing IDE debugging, with the main difference being that you will probably want to filter out the Eclipse debugger traffic on port 8000 so you can focus on the SOAP request and response packets. To do this, use a Wireshark capture filter of port not 8000 prior to starting the network monitoring or a display filter of !(tcp.port == 8000) after it has already started.

Steps for debugging WSP's and SOAP clients with Eclipse:

  1. Import the DoubleIt project into the Eclipse IDE. Make sure you've imported your project into Eclipse as described in Step #5 of the DoubleIt tutorial. Because the maven-eclipse-plugin defined in DoubleIt/pom.xml has the downloadSources element set to true, your local Maven repository will be loaded not just with the necessary dependency JARs but also their source JARs, necessary for tracing software code during debugging. By opening the ".classpath" file in the base directory of each project imported, you should be able to see via the sourcepath attribute that points to those source JARs, for example for the CXF-based DoubleIt:

    <classpath> ... <classpathentry kind="var" path="M2_REPO/org/apache/cxf/cxf-rt-bindings-soap/2.4.1/cxf-rt-bindings-soap-2.4.1.jar" sourcepath="M2_REPO/org/apache/cxf/cxf-rt-bindings-soap/2.4.1/cxf-rt-bindings-soap-2.4.1-sources.jar"/> <classpathentry kind="var" path="M2_REPO/org/apache/cxf/cxf-rt-bindings-xml/2.4.1/cxf-rt-bindings-xml-2.4.1.jar" sourcepath="M2_REPO/org/apache/cxf/cxf-rt-bindings-xml/2.4.1/cxf-rt-bindings-xml-2.4.1-sources.jar"/> ... </classpath>

    ...and for Metro:

    <classpath> ... <classpathentry kind="var" path="M2_REPO/org/glassfish/metro/webservices-api/2.1/webservices-api-2.1.jar" sourcepath="M2_REPO/org/glassfish/metro/webservices-api/2.1/webservices-api-2.1-sources.jar"/> <classpathentry kind="var" path="M2_REPO/org/glassfish/metro/webservices-rt/2.1/webservices-rt-2.1.jar" sourcepath="M2_REPO/org/glassfish/metro/webservices-rt/2.1/webservices-rt-2.1-sources.jar"/> ... </classpath>
  2. Debug the client. First deploy the WSP on Tomcat as explained in the DoubleIt tutorial. Next open the WSClient.java file within Eclipse and place a breakpoint on one of the lines of code. Then, debug the client by right-clicking the source file in the Editor and selecting Debug As -> Java Application. When the code reaches your breakpoint, you'll automatically move into Debug view, suitable for tracing line-by-line, stepping into and out of functions, placing additional breakpoints for subsequent runs, resuming non-stop execution, etc. The debug toolbar shown at the upper right part of the screen below provides easy access to the various debugging commands. By running the mouse over those buttons, the Tool Tip pop-ups will tell you the task each button performs.

  3. Debug the WSP. In the service-bundle project, open up the DoubleItPortTypeImpl class and place a breakpoint next to the return statement. Now we need to set up Tomcat to allow for remote debugging. Leveraging information gathered from the Tomcat Wiki and a WS02 Axis2/Eclipse debugging article, here is the process I followed:

    1. Configure a Tomcat debugging listener port. Debugging a web service running on Tomcat requires a second port for which the listener (the Eclipse IDE in this instance) receives feedback of the present line of code that Tomcat is running. This port also allows the IDE to communicate with Tomcat to perform the standard debugging tasks: breakpoints, line-by-line tracing, etc. To add this port, create a CATALINA_OPTS environment variable as follows:

      export CATALINA_OPTS="-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8000"

      Here, we are using port 8000 for the IDE <-> Tomcat debugging communication, while web service processes will still run on the usual 8080 port.

    2. Stop and restart Tomcat so it picks up this new parameter.

    3. Create a Remote Java Application configuration for the service-war subproject. Right click the service-war folder in the Navigator or Package Explorer View and select Debug As... -> Debug Configurations.... From the left-side configuration list, select "Remote Java Application" and right-click "New". Make sure the options shown in the dialog below are configured correctly, namely the debugging listener port above is correctly chosen. Now press the Debug button to start debugging.

    Next, activate the WSP breakpoints by running the WSClient. How you do this depends on whether you wish to simultaneously debug the Client:

    • Debugging the service only: To activate breakpoints in the WSP code only, right-click WSClient.java in the IDE and select Run As -> Java Application. Alternatively, since the client is a Maven project, you can navigate to its directory from a command-line prompt and enter mvn exec:exec.
    • Debugging both the client and WSP: To activate both client- and service-side breakpoints, right-click WSClient.java in the IDE and select Debug As -> Java Application just as you did in the previous step. The debugger will provide separate debugging windows for the client and service.
  4. (Optional) Manually import the CXF or Metro source code into Eclipse. This step is probably not necessary for most debugging cases. So long as the sourcepath attributes are populated in the Eclipse .classpath files, you should be able to trace from your code into the web service stack's code during any debug process. Also, if an error stack trace is present in Eclipse's Console window while debugging, double-clicking on any CXF or Metro source file listed in that trace will bring up that file in the editor window. Either way, you can add breakpoints in the CXF/Metro source and run another debugging session.

    For ease of bringing up specific CXF or Metro source files you may wish to import the web service stack as projects into Eclipse. That will allow you to bring up any CXF/Metro source file by using Ctrl-Shift-R instead of needing to debug into it. The source code versions to import depend on the goal--to locate a bug, you'll want to import the version that your project is using; to submit a patch to fix a bug, you'll want to import the most recent version of the specific branch (e.g., CXF 2.3.x, 2.4.x, 2.5.x, etc.) of the web service stack and reconfigure your WSP and/or SOAP client to use this version.

    Both Metro and CXF source code are Mavenized, so downloading the desired version of the web service stack and running mvn clean install eclipse:eclipse -Declipse.useProjectReferences=false (recommend adding -Pfastinstall for CXF) will provide you Eclipse projects for your web service stack that you can subsequently import into the IDE. You can either download source code JARs available from the project website or use a Subversion checkout of a specific tag to get the source code--see the this entry for links on downloading and building the web service stack.

    Note the purpose of the -Declipse.useProjectReferences=false in the above command is to have each web service stack submodule point to other dependencies in your local Maven repository rather than other submodules within Eclipse--you can view the .classpath files in the web service stack submodules you import to confirm this is happening. That allows you to import some and not all of of the web service stack submodules in the workspace. Otherwise, the Eclipse debugger will fail to run your SOAP project, giving error messages that some web service stack dependencies are not in your Eclipse workspace.

    As explained in the CXF guide, after the web service stack source projects are imported, run mvn eclipse:clean eclipse:eclipse -Declipse.workspace=C:\path\to\my\Eclipse\Workspace from the DoubleIt root folder (and then refresh the DoubleIt subprojects in Eclipse). The -Declipse.workspace option allows Eclipse to link the DoubleIt code to the CXF or Metro source files you just imported into the Eclipse workspace rather than source files in your local Maven repository. This is necessary for WSP or SOAP client debugging to activate breakpoints set within the IDE-held web service stack source files.

Categories:

Web Services Links (24 July 2011)

Glen Mazza - Sun, 07/24/2011 - 13:00
Categories:

Website mashup with Apache Camel

Jean-Baptiste Onofré - Fri, 07/22/2011 - 09:20
Mashup ? You are browsing on some websites and you see an interesting information, that you want to poll to be used into your system. Unfortunately, you don’t know the website provider, and you don’t know if a “plug” is provided, for instance a WebService. So you have to find a way to get the [...]
Categories: Jean-Baptiste Onofré

Creating a Java-first web service using CXF or Metro

Glen Mazza - Tue, 07/19/2011 - 13:00

This article shows the changes needed to the WSDL-first DoubleIt tutorial to convert it to a start-from-Java process. Follow along with the original tutorial except for these changes:

  • In Step #3, the service/pom.xml file will need to be changed to now use the web service stack's Java-to-WSDL utility (CXF docs, Metro docs). Also, the Assembly plugin's jaxws-jar.xml file will need modification for the different classes used by the client. Replace these files with the following:

    DoubleIt/service/pom.xml: <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> <modelVersion>4.0.0</modelVersion> <parent> <groupId>org.gmazza.blog.basic-doubleit</groupId> <artifactId>basic-doubleit</artifactId> <version>1.0-SNAPSHOT</version> </parent> <artifactId>service-bundle</artifactId> <name>Web Service Provider</name> <packaging>jar</packaging> <url>http://maven.apache.org</url> <build> <plugins> <!-- Below plugin provides a separate JAR for the JAX-WS artifacts (i.e., the objects created by running wsdl2java or wsimport), as this JAR will also be used by the SOAP client. More info: http://maven.apache.org/plugins/maven-assembly-plugin/ --> <plugin> <artifactId>maven-assembly-plugin</artifactId> <version>2.2-beta-1</version> <configuration> <descriptors> <descriptor>src/assembly/jaxws-jar.xml</descriptor> </descriptors> <appendAssemblyId>true</appendAssemblyId> <attach>true</attach> </configuration> <executions> <execution> <id>make-assembly</id> <phase>package</phase> <goals> <goal>single</goal> </goals> </execution> </executions> </plugin> </plugins> <pluginManagement> <plugins> <plugin> <groupId>org.apache.felix</groupId> <artifactId>maven-bundle-plugin</artifactId> <version>2.3.4</version> <extensions>true</extensions> </plugin> </plugins> </pluginManagement> <!-- Name of the generated WAR file --> <finalName>doubleit</finalName> </build> <profiles> <profile> <id>CXF</id> <!-- To use Metro by default, move activation element to its profile below --> <activation> <activeByDefault>true</activeByDefault> </activation> <build> <plugins> <plugin> <groupId>org.apache.cxf</groupId> <artifactId>cxf-java2ws-plugin</artifactId> <version>${cxf.version}</version> <executions> <execution> <id>process-classes</id> <phase>process-classes</phase> <configuration> <className>service.DoubleItPortTypeImpl </className> <genWsdl>true</genWsdl> <verbose>true</verbose> </configuration> <goals> <goal>java2ws</goal> </goals> </execution> </executions> </plugin> <plugin> <groupId>org.apache.felix</groupId> <artifactId>maven-bundle-plugin</artifactId> <configuration> <instructions> <Bundle-SymbolicName>${project.artifactId}</Bundle-SymbolicName> <Require-Bundle>org.apache.cxf.bundle,org.springframework.beans</Require-Bundle> <Export-Package>service</Export-Package> </instructions> </configuration> </plugin> </plugins> </build> </profile> <profile> <id>Metro</id> <build> <plugins> <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>jaxws-maven-plugin</artifactId> <version>1.10</version> <executions> <execution> <goals> <goal>wsgen</goal> </goals> <configuration> <sei>service.DoubleItPortTypeImpl</sei> <genWsdl>true</genWsdl> <keep>true</keep> </configuration> </execution> </executions> </plugin> </plugins> </build> </profile> </profiles> </project> DoubleIt/service/src/assembly/jaxws-jar.xml: <assembly> <id>jaxws</id> <formats> <format>jar</format> </formats> <includeBaseDirectory>false</includeBaseDirectory> <files> <file> <source>target/classes/service/DoubleItPortType.class</source> <outputDirectory>/service</outputDirectory> </file> </files> </assembly>
  • Skip Step #4, as there is no WSDL for Java-first development.

  • For Step #6, remove Metro's wsdl and CXF's wsdlLocation attribute from their respective configuration files.

  • For Step #7, use the following web service interface and implementation class instead:

  • DoubleItPortType.java: package service; import javax.jws.WebService; import javax.jws.WebMethod; @WebService public interface DoubleItPortType { public int doubleIt(int numberToDouble); } DoubleItPortTypeImpl.java: package service; import javax.jws.WebService; @WebService(targetNamespace = "http://www.example.org/contract/DoubleIt", endpointInterface = "service.DoubleItPortType", serviceName = "DoubleItService", portName = "DoubleItPort") public class DoubleItPortTypeImpl implements DoubleItPortType { public int doubleIt(int numberToDouble) { return numberToDouble * 2; } }
  • For Step #9, use the following client class instead:

    package client; import javax.xml.namespace.QName; import javax.xml.ws.Service; import javax.xml.ws.soap.SOAPBinding; import java.net.URL; import service.DoubleItPortType; public class WSClient { private static final QName SERVICE_NAME = new QName("http://www.example.org/contract/DoubleIt", "DoubleItService"); private static final QName PORT_NAME = new QName("http://www.example.org/contract/DoubleIt", "DoubleItPort"); public static void main (String[] args) throws Exception { String endpointAddress = "http://localhost:8080/doubleit/services/doubleit"; Service service = Service.create(new URL(endpointAddress +"?wsdl"), SERVICE_NAME); DoubleItPortType port = service.getPort(DoubleItPortType.class); doubleIt(port, 10); doubleIt(port, 0); doubleIt(port, -10); } public static void doubleIt(DoubleItPortType port, int numToDouble) { int resp = port.doubleIt(numToDouble); System.out.println("The number " + numToDouble + " doubled is " + resp); } }

Additional Resources

Categories:

Apache Karaf 2.1.x branch is in end of life, 2.1.6 available

Jean-Baptiste Onofré - Sun, 07/17/2011 - 20:13
We (The Apache Karaf team) have decided to switch Karaf 2.1.x branch into End Of Life mode. We released Karaf 2.1.6 which is the last version on this branch: http://karaf.apache.org/index/community/download/karaf-2.1.6-release.html We encourage all users to upgrade to Karaf 2.2.2, which is the latest Karaf stable release. This announce is in preparation of the next Karaf [...]
Categories: Jean-Baptiste Onofré

Apache Karaf Cellar 2.2.1 Released

Jean-Baptiste Onofré - Mon, 07/11/2011 - 15:15
Apache Karaf Cellar 2.2.1 has been released today. Cellar is a Karaf sub-project which aim to provide a clustering solution for Karaf. Quick start To enable Cellar into a Karaf, you just have to install the Cellar feature. First, register the Cellar features descriptor in your running Karaf instance: karaf@root> features:addurl mvn:org.apache.karaf.cellar/apache-karaf-cellar/2.2.1/xml/features Now, you can [...]
Categories: Jean-Baptiste Onofré

Weekend Talendization: Tour of Talend ESB and Talend ESB Studio

Glen Mazza - Fri, 07/08/2011 - 13:00

Talend colleague Renat Zubairov has created five short screencasts on working with Talend ESB and the new Talend ESB studio. Each screencast builds on the previous one, so it's best to follow them all in order. Most software covered is freely downloadable from the Talend site. (The main exception is the Talend Administration Center in the second screencast, which is part of the commercial Talend ESB Enterprise Edition offering.)

Screencast listing:

  1. Preparing the runtime environment for deploying Data Services: http://www.screenr.com/DxHs
  2. Installation and initial configuration of the Talend Administration Center for Talend ESB: http://www.screenr.com/3ZHs
  3. How to start Talend ESB Studio, and short overview of its available perspectives: http://www.screenr.com/IZHs
  4. Creating a simple Data Service Provider and Data Service Consumer, and running them in Talend ESB Studio: http://www.screenr.com/0kHs
  5. Deploying and running data services created in Talend ESB Studio within the Talend ESB Runtime: http://www.screenr.com/ckHs
Categories:

Creating a SOAP client with either Apache CXF or GlassFish Metro

Glen Mazza - Tue, 07/05/2011 - 19:51

This tutorial shows how SOAP clients can be created using either Metro or Apache CXF. We'll be creating a client for the eBay Shopping Web Service, which provides a full range of search and retrieval capabilities for items being auctioned on the eBay site. Maven will be used as our build tool for this project.

To use the eBay service, you will first need to sign up for a eBay developer account (free as of this writing)--the API license agreement is also available on that page. For more information on working with the eBay shopping API developer documentation and a help forum is available.

  1. Create the project file structure. We'll follow Maven's standard directory layout for this step. Create a directory for your new project and, from there, copy-and-paste the appropriate set of mkdir commands:

    Linux: mkdir -p src/main/java/client mkdir -p src/main/resources Windows: mkdir src\main\java\client mkdir src\main\resources
  2. Save the eBay WSDL locally. Download the eBay Shopping API WSDL and save it as ShoppingService.wsdl in the src/main/resources folder.

  3. Create the Maven pom file for the project. Place the following pom.xml file in the base directory of the new project. It is configured to use CXF by default; if you wish to use Metro instead, either move the activation element bolded below from the CXF profile to the Metro one or use the -PMetro switch discussed in a later step.

    <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>client</groupId> <artifactId>WSClient</artifactId> <version>1.0-SNAPSHOT</version> <name>Sample SOAP Client</name> <packaging>jar</packaging> <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>2.3.2</version> <configuration> <source>1.6</source> <target>1.6</target> </configuration> </plugin> <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>exec-maven-plugin</artifactId> <version>1.2</version> <executions> <execution> <goals> <goal>exec</goal> </goals> </execution> </executions> <configuration> <executable>java</executable> <arguments> <argument>-classpath</argument> <classpath /> <!-- Uncomment below for debugging with Metro. --> <!--argument> -Dcom.sun.xml.ws.transport.http.client.HttpTransportPipe.dump=true </argument--> <!-- Uncomment below for debugging with CXF. --> <!--argument> -Djava.util.logging.config.file=${env.CXF_HOME}/etc/logging.properties </argument--> <argument>client.WSClient</argument> <!-- Modify argument below for the item you wish to search eBay for. --> <argument>camera</argument> </arguments> </configuration> </plugin> </plugins> </build> <profiles> <profile> <id>CXF</id> <!-- To use Metro by default, move this activation element to its profile below --> <activation> <activeByDefault>true</activeByDefault> </activation> <properties> <cxf.version>2.4.1</cxf.version> </properties> <dependencies> <dependency> <groupId>org.apache.cxf</groupId> <artifactId>cxf-rt-frontend-jaxws</artifactId> <version>${cxf.version}</version> </dependency> <dependency> <groupId>org.apache.cxf</groupId> <artifactId>cxf-rt-transports-http</artifactId> <version>${cxf.version}</version> </dependency> </dependencies> <build> <plugins> <plugin> <groupId>org.apache.cxf</groupId> <artifactId>cxf-codegen-plugin</artifactId> <version>${cxf.version}</version> <executions> <execution> <goals> <goal>wsdl2java</goal> </goals> <configuration> <sourceRoot>${basedir}/target/generated-sources</sourceRoot> <wsdlOptions> <wsdlOption> <wsdl> ${basedir}/src/main/resources/ShoppingService.wsdl </wsdl> </wsdlOption> </wsdlOptions> </configuration> </execution> </executions> </plugin> </plugins> </build> </profile> <profile> <id>Metro</id> <dependencies> <dependency> <groupId>org.glassfish.metro</groupId> <artifactId>webservices-rt</artifactId> <version>2.1</version> </dependency> </dependencies> <build> <plugins> <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>jaxws-maven-plugin</artifactId> <executions> <execution> <goals> <goal>wsimport</goal> </goals> <configuration> <wsdlDirectory>src/main/resources</wsdlDirectory> <wsdlFiles> <wsdlFile>ShoppingService.wsdl</wsdlFile> </wsdlFiles> <sourceDestDir>${basedir}/target/generated-sources</sourceDestDir> </configuration> </execution> </executions> </plugin> </plugins> </build> </profile> </profiles> </project>

    Although not necessary to complete this tutorial, you may wish to import this project into your IDE at this time. If you are using Eclipse, run mvn eclipse:clean eclipse:eclipse -DdownloadSources=true from the project base directory. This will create an Eclipse project with the web service stack's JAR dependencies tied to their source code (useful for debugging). From Eclipse you can then use the menu item File->Import->General->Existing Projects into Workspace to import the project.

  4. Create the SOAP Client. Add the following WSClient.java file to the src/main/java/client directory. Be sure to add your eBay App ID where indicated in the code--you'll find it on the MyAccount page after you've logged into the eBay developer site. (Also, you may need to update the WSDL version number from the 725 listed below. You can find this number in the wsdl:service section at the bottom of the eBay WSDL.)

    package client; import java.util.List; import javax.xml.ws.BindingProvider; import ebay.apis.eblbasecomponents.FindPopularItemsRequestType; import ebay.apis.eblbasecomponents.FindPopularItemsResponseType; import ebay.apis.eblbasecomponents.SimpleItemArrayType; import ebay.apis.eblbasecomponents.SimpleItemType; import ebay.apis.eblbasecomponents.Shopping; import ebay.apis.eblbasecomponents.ShoppingInterface; public class WSClient { public static void main(String[] args) { if (args.length != 1) { System.out.println("Usage: WSClient <search item>"); System.exit(-1); } WSClient wsc = new WSClient(); wsc.run(args[0]); } private void run(String searchItem) { try { ShoppingInterface port = new Shopping().getShopping(); BindingProvider bp = (BindingProvider) port; // retrieve the URL stub from the WSDL String ebayURL = (String) bp.getRequestContext().get( BindingProvider.ENDPOINT_ADDRESS_PROPERTY); // add eBay-required parameters to the URL String endpointURL = ebayURL + "?callname=FindPopularItems&siteid=0" + "&appid=????" + "&version=725&requestencoding=SOAP"; // replace the endpoint address with the new value bp.getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, endpointURL); FindPopularItemsRequestType req = new FindPopularItemsRequestType(); req.setQueryKeywords(searchItem); FindPopularItemsResponseType resp = findPopularItems(port, req); SimpleItemArrayType siat = resp.getItemArray(); List<SimpleItemType> lsit = siat.getItem(); for (SimpleItemType sit : lsit) { System.out.println("\n\n" + formatSimpleItemType(sit)); } } catch (Exception e) { System.out.println("Exception: " + e.getMessage()); } } protected FindPopularItemsResponseType findPopularItems(ShoppingInterface port, FindPopularItemsRequestType req) { return port.findPopularItems(req); } protected String formatSimpleItemType(SimpleItemType sit) { StringBuffer sb = new StringBuffer(); sb.append("Category: " + sit.getPrimaryCategoryName()); sb.append("\nItem ID: " + sit.getItemID()); sb.append("\nURL: " + sit.getViewItemURLForNaturalSearch()); return sb.toString(); } }
  5. Build the project and test the client. Note the supplied pom.xml above, in the exec-maven-plugin element is hardcoded to search eBay for cameras. Update this value if you wish to search for something else.

    Run mvn clean install exec:exec from a terminal window. With this command Maven will generate the jax-ws artifacts, compile all classes, and run the WSClient SOAP client. Note you can append a -PCXF or -PMetro setting to the command above to switch between the web service stacks (without this option, Maven uses the stack defined within the default profile in the pom.xml). Testing with both stacks can be helpful in troubleshooting SOAP call problems because the two stacks often give different error messages for the same problem.

    If you're new to JAX-WS, you might wish to take a look at the JAX-WS artifacts generated by the Maven build process in the target/generated-sources folder. JSR 224, the JAX-WS 2.0 Specification, formally describes these classes, which we subsequently used when creating the SOAP client. Classes are generated for the objects defined in the wsdl:types section (e.g., AddressType, AmountType), wsdl:message request/response pairs (e.g., GetItemStatusRequestType and GetItemStatusResponseType), the Service Endpoint Interface (SEI) listing the operations in the wsdl:portType (ShoppingInterface), and the Service class (Shopping) used by the SOAP client when connecting to the web service provider. Note that the Service class hardcodes the location of the WSDL file you just used and uses that file by default when making web service calls.

    Sample search output for a run on 5 July 2011:

    Category: Consumer Electronics:Gadgets:Surveillance:Surveillance Cameras:Wireless Cameras:Color Item ID: 390120901957 URL: http://cgi.ebay.com/Wireless-Spy-Nanny-Mini-Micro-Camera-FULL-SYSTEM-/390120901957 Category: Cameras & Photo:Digital Cameras Item ID: 260615184611 URL: http://cgi.ebay.com/Sunglasses-DV-Mobile-Eyewear-Recorder-Camera-DV-CW004-/260615184611 Category: Consumer Electronics:Gadgets:Surveillance:Security Systems Item ID: 180684987751 URL: http://cgi.ebay.com/ZMODO-4-CH-CCTV-Security-DVR-LED-IR-Camera-System-500GB-/180684987751 ...several more items...

Notes:

  1. The pom.xml file includes an option for activating logging/debug output for either web service stack--just uncomment the necessary line as shown in that file. Note that without logging activated, Apache CXF is quite verbose in its terminal output, but the default CXF logging configuration file referenced by the pom file curtails most/all of that output. For more advanced debugging, tools such as Wireshark may be of help.

  2. For developer convenience, the signatures of the SEI methods can sometimes be changed between "wrapper style" and "non-wrapper style" by setting a JAX-WS binding property as explained here.

  3. Web Service-stack specific information on using Maven is available for CXF here and GlassFish Metro here.

  4. There is a more sophisticated eBay trading API available. The trading API involves actual bidding, purchasing, and other financial details requiring more security. Applications created with the trading API require running against a test sandbox server until eBay does compatibility checks of your application to make sure data calls are sufficiently secure. The Shopping API we're using here, however, just makes nonsensitive read-only queries of available products, so sandbox calls are never needed.

  5. See my blog index for more web service-related resources and articles.

Categories:

Detroit's 1826 Independence Day celebration

Glen Mazza - Mon, 07/04/2011 - 19:43

From the Detroit Gazette, July 11, 1826, page 2:

The manner in which the 50th anniversary of the Nation's Independence was celebrated in this city reflects the highest honor upon the patriotism of its citizens.

The dawn of the Jubilee was welcomed by the national salute of 24 guns. At about ten o'clock the citizens repaired to the Protestant Church, where proper religious exercises were perfomed and a sermon, replete with excellent and appropriate sentiments, was delivered by the Rev. Mr. Wells, from the 17th Psalm--"Praise ye the Lord, all ye nations: praise him, all ye people. For his merciful kindness is great towards us: and the truth of the Lord endureth forever. Praise ye the Lord."

After the exercises at the Church were terminated, the citizens repaired to the Council House, were a procession was formed, agreeably to the order of the day heretofore published. Many of the officers of the militia were in handsome uniforms--Capt. Cook's company of dragoons were also in their appropriate dress; and added much to the appearance of the procession. Among those who took their place in the procession, were the Hon. JOHN TRUMBULL, known throught the Union for his learning, and for his patriotic writings during our revolutionary struggle--and the Hon. JAMES WITHERELL, Maj. THOMPSON MAXWELL, and Col. STEPHEN MACK, all veteran "continentals." The appearance of the Detroit Mechanic Society, each member of which wore an appropriate badge upon his left breast, was creditable to the association.

The procession having been formed, it proceeded, accompanied with martial music, down Randolph Street to Woodbridge Street and down the latter to Woodward Avenue--it then proceeded to the Presbyterian Church, which was soon filled to overflowing. The exercises in the Church were conformable to the arrangements published last week. The Throne of Grace was first addressed by the Rev. Mr. Wells, who, though fatigued with the exertions of the morning, and in ill health, effectually directed the thoughts of his audience to that Great Source, from whence flows all our blessings and privileges as a nation. The Declaration of Independence was read by Col. H.J. Hunt, who introduced it by some brief and truly appropriate and patriotic remarks. It was not read for the purpose of exciting hatred, or keeping alive animosities, which were created by the most overbearing and despotic measures of a powerful government, against a weak yet brave people, who had endured almost every suffering in the catalogue of human misery, to obtain a comparative liberty--but it was annually referred to, as the best compendium of those wrongs which authorized and urged our fathers to hold the people of Great Britain as they held the rest of the world, "enemies in war, in peace friends."

The Oration was read by A.G. Whitney, Esq. It was from the pen of the venerable author of "M'Fingal", and was such as might be expected from a writer, who in "the times that tried men's souls," was held in as great dread by the Tories and enemies of our independence, as were Morgan's rifle-men, or the Virginia dragoons.

After the reading of the oration, the Rev. William Simmons addressed the Throne of Grace, and the exercises closed with an Anthem. Appropriate Psalms had been selected for the occasion, and they were sung, by the choir, under the direction of Mr. E. P. Hastings, with correctness and taste.

The committee of arrangements deserve praise for the elegant manner in which the church was decorated.

After leaving the church the procession was again formed, and proceeded to the Hotel of Capt. Woodworth, who had prepared a bountiful dinner, in the large new store-house of Mr. A. Berthelet. At three o'clock, those citizens who wished to partake of the dinner, together with the Mechanics' Society, the whole amounting to nearly two hundred, moved in procession to the store house and took their seats at the table--John P. Sheldon presiding, assisted by Col. H.J. Hunt, as vice-president.

Categories:

What happened at Talend R&D summit

Sergey Beryozkin - Mon, 07/04/2011 - 13:12
Last week many of us had a chance to attend to a 3 day R&D event organized by Talend in Paris. And what a summit it was.

It was good to meet Dan, JB, Christian, our colleagues from Talend Bonn's office and of course the hosts, people who organized and run the event. The only regret I have I could not play our regular chess game with Hadrian - but I guess we have plenty of time in the future to do it again :-)

I've had a chance to attend to similar events before and I did like it very much, but this last event stands on its own. Talend is still a young company but one can't help being impressed by what this team has already achieved. The tooling is very impressive, be it Talend ESB, core Talend Data Integration or Master Data Management UI suites. They understand what managing data, jobs, processes is about, what good UI is about.

Talend ESB team has had cool demos showing how ESB consumers and producers backed up by Apache CXF can be wired in together, run as live jobs, exported as OSGI bundles, with consumers locating endpoints and users seeing the management statistics. It is really impressive, I thought it was. The new Camel Builder is the tool to explore too - it also supports linking to Talend Jobs with each Job possibly representing a super complex chain on its own.

Talend team works very hard and this team knows how to play hard too :-).

Good to be part of Apache and Talend teams...
Categories: Sergey Beryozkin

I&#8217;m now officially Talend employee

Jean-Baptiste Onofré - Mon, 07/04/2011 - 10:40
After 8 years worked at Fimasys, I decided to move last December. Fimasys is a great company but not purely middleware oriented (it’s a financial software provider). I was receiving offers from quite long time and I decided to make a choice between Talend and Fusesource. Both companies are great and I know a lot [...]
Categories: Jean-Baptiste Onofré

Apache Karaf 2.2.2 available

Jean-Baptiste Onofré - Mon, 07/04/2011 - 09:25
A new Apache Karaf version is available. If it’s mainly a bug fixes release, it includes some small enhancements. Especially, we added a completer for shell aliases. It means that you add a new command alias in etc/shell.init.script, the TAB key will look for aliases in addition of pure commands. Another interesting enhancement used in [...]
Categories: Jean-Baptiste Onofré

Web Services Links (3 July 2011)

Glen Mazza - Sun, 07/03/2011 - 17:58

Web service related links of interest this week:

Categories:

Video: Deploying CXF web services with Talend Services Factory

Glen Mazza - Thu, 06/30/2011 - 17:16
I created a YouTube video for my WSDL-first tutorial for those who prefer a visual explanation for building web services with Apache CXF. Enjoy!
Categories:

Custom token validation in Apache CXF 2.4

Colm O hEigeartaigh - Tue, 06/28/2011 - 15:37
A previous blog post has covered validators in Apache WSS4J 1.6, why they were introduced, what default implementations ship with WSS4J, etc. It ends with a paragraph on how to use a custom Validator implementation with Apache CXF 2.4. This post expands further on this topic.

1) Use-cases for custom Token Validation

Let's consider first of all the use-cases for specifying a custom Validator implementation in CXF. When a security header is being processed by WSS4J, it delegates each security token to a Processor implementation, depending on the QName of the token. In WSS4J 1.6, Processors do not do any validation of extracted credentials from a token, they merely process it, make sure it meets basic requirements, etc. Validation is delegated to a Validator interface which is associated with that Processor implementation.

However, there are many possible use-cases where a user may wish to replace or remove or extend the default validation behaviour associated with a particular security token. Some examples include:
  1. Validating a UsernameToken, where the CallbackHandler implementation does not have access to the password.
  2. Validating a BinarySecurityToken of some custom type.
  3. Validating the attributes of a received SAML Assertion
  4. Validating a Timestamp in a more tolerant manner than the default.
  5. Dispatching a received security token to a third-party security service for validation/authentication.
2) Configuring custom Validators in CXF
    The CXF SecurityConstants class (javadoc) defines some configuration items to override the default validators used to validate a received security token. The values associated with each configuration option must correspond to an implementation of the Validator interface. The configuration tags are:
    1. "ws-security.ut.validator" - Override UsernameToken validation.
    2. "ws-security.saml1.validator" - Override SAML1 token validation.
    3. "ws-security.saml2.validator" - Override SAML2 token validation.
    4. "ws-security.timestamp.validator" - Override Timestamp validation.
    5. "ws-security.signature.validator" - Override trust verification on a signature
    6. "ws-security.bst.validator" - Override BinarySecurityToken validation.
    To disable the validation of a particular token, specify the NoOpValidator as the value of the configuration tag corresponding to that token.

    3) Using Validators with WS-Trust

    To see the power and flexibility of the approach of separating processing from validation, consider the STSTokenValidator that ships with CXF 2.4. This validator implementation has the ability to dispatch a received BinarySecurityToken, UsernameToken, or SAML Assertion to an STS (Security Token Service) for validation via WS-Trust. On invocation, it delegates the credential to another validator (STSSamlAssertionValidator). This validator essentially catches an exception caused by a signature validation failure of the SAML Assertion and sets a flag. Only if signature validation is unsuccessful does the STSTokenValidator dispatch the token to the STS for validation.

    An example of how to configure the STSTokenValidator to validate a SAML1 Assertion against an STS in spring is as follows:

    <jaxws:endpoint ...>
      <jaxws:properties>
        <entry key="ws-security.saml1.validator">
          <bean class="org.apache.cxf.ws.security.trust.STSTokenValidator"/>
        </entry>
        <entry key="ws-security.sts.client">
          <bean class="org.apache.cxf.ws.security.trust.STSClient">
            <constructor-arg ref="cxf"/>
            <property name="wsdlLocation" value="..."/>
            <property name="serviceName" value=".../>
            <property name="endpointName" value="..."/>
             ...       
           </bean>           
         </entry>
       </jaxws:properties>
     </jaxws:endpoint>

    The STSTokenValidator also has the ability to obtain a transformed token from the STS and store it in the credential, where it is available as part of the WSSecurityEngineResult under the TAG_TRANSFORMED_TOKEN tag.
    Categories: Colm O hEigeartaigh

    WADL First Development in CXF

    Sergey Beryozkin - Sun, 06/26/2011 - 23:20
    The auto-generation of WADL documents has been supported in CXF JAX-RS for a while. Letting users get a WADL instance and use a tool like soapUI to test a live RESTful endpoint is very useful.

    Don't get distracted by the fact WADL is not favoured by some REST advocates. Being able to test a live endpoint without spending time on writing a dedicated test code is good.

    CXF JAX-RS also offers a CodeGenerator filter which can be configured on test/development/POC servers for possible users being able to download the source code, compile it and start experimenting immediately. Java is just the only option there for now but of course more languages can be supported easily.

    That is all fine, but one limitation there is that what is possibly the most important WADL feature, underrated at the moment, is not really utilized. WADL is very resource centric and IMHO it's a perfect language for bridging would-be RESTful application modeling tools with the actual code. I'm not referring to UML-like modeling but a more high level approach with a tool linking entities representing root resources, subresources and data and using WADL as a internal link between a specific tool data representation and a wadl2java code generator. I'm not referring to a complex WADL XML editor here.

    All/most of us do Java-first development and it's kind of easy to assume that nobody will need a document-first development. But the document-first approach has its followers as it has its benefits.

    CXF is all about choice, options, diversity and letting users get their web services projects done using the strategies preferred in their teams. CXF 2.4.1 offers a server side WADL-first development support - give it a try and enjoy.
    Categories: Sergey Beryozkin

    Web Services Links (26 June 2011)

    Glen Mazza - Sun, 06/26/2011 - 13:00

    Web service related links of interest this week:

    Categories:

    Talend joins JCP and JSR-339

    Sergey Beryozkin - Fri, 06/24/2011 - 22:46
    This week Talend has joined Java Community Process (JCP) and JSR-339 (JAX-RS 2.0) Expert Group (EG) with myself acting as the company representative in this EG.

    This is a good news for us working on Apache CXF as it's another vote of confidence from Talend in CXF continuing positioning itself as the best-of-breed web services framework for developing WS and REST compliant and robust service endpoints and consumers which just work.

    Talend has a history of supporting open source projects and communities. Joining JCP and supporting JAX-RS 2.0 specification is another step in that direction, simply because JAX-RS 2.0 will become important for Apache CXF users building RESTful services.

    Another reason is that Talend has a lot of experience in data-integration technologies. Talend tooling is powerful and impressive which will be a subject of another post. REST and data are good matches. Many interesting opportunities will arise for exposing data as RESTful endpoints, letting people search and link to the data of interest. It's natural Talend would like to get involved in JAX-RS 2.0.

    See this blog entry for more information.



    Categories: Sergey Beryozkin

    Talend joins the JCP

    Daniel Kulp - Wed, 06/22/2011 - 16:11
    One of the important differentiators between Apache CXF and some of it’s competitors has been it’s support for standards, both “on the wire” standards like SOAP and API standards like JAX-WS and JAX-RS. When Apache resigned from the JCP last year, there was a lot of concern about whether CXF would be able to continue [...]
    Categories: Daniel Kulp

    7000 commits later&#8230;&#8230;

    Daniel Kulp - Mon, 06/20/2011 - 17:43
    On July 22, 2005, I did my first commit into the Apache subversion repository. That commit was the first part of bringing Apache CXF (was called CeltixFire at the time) to Apache. This morning, according to svnsearch, I committed my 7000th change. That’s a lot of changes. Kind of silly milestone, but I’m proud of [...]
    Categories: Daniel Kulp

    Pages

    Subscribe to Talend Community Coders aggregator