Latest Activity

Use Camel, CXF and Karaf to implement batches

Jean-Baptiste Onofré - Tue, 08/23/2011 - 22:15
Introduction Apache Camel has not be designed to be used for implementing batch tasks. For instance, if your Camel route has a consumer endpoint polling files in a directory, Camel will periodically and indefinitely monitor the folder and poll any new incoming files. It’s not a batch behavior: in batch mode, we want to run [...]
Categories: Jean-Baptiste Onofré

Deploying CXF- or Metro-based web services to Oracle WebLogic Server

Glen Mazza - Tue, 08/23/2011 - 13:00

Deploying a CXF- or Metro-based web service to Oracle WebLogic Server has never been easier--I was able to get the WAR generated by the WSDL-first DoubleIt tutorial to work on Oracle WebLogic 10.3.5 out of the box, using either web service stack. However, due to potential classloader conflicts you may wish to deploy an EAR to WebLogic following the instructions below. By default, WebLogic uses its own JARs before those that you include within the WAR, which can create version mismatches and other runtime problems. The weblogic-application.xml configuration file stored within the EAR gets around this problem by allowing developers to specify the Java packages that need to loaded from the EAR instead of from WebLogic's default classloader.

Steps involved in moving the DoubleIt tutorial from a WAR-based Tomcat deployment to an EAR-based WebLogic one are as follows:

  1. Download the source code from the DoubleIt tutorial. The download uses CXF by default; make sure you have made the necessary web.xml and Maven pom file changes as explained in that tutorial if you're using Metro instead. If you haven't already, you may wish to follow that tutorial to confirm it is working on Tomcat for you before proceeding.

  2. Create a new "ear" Maven submodule for the project. This will be the project's fourth submodule, alongside client, service, and war. Make sure it has the following subfolders:


    Place the following weblogic-application.xml file under META-INF:

    <?xml version="1.0" encoding="UTF-8"?> <weblogic-application xmlns="” xmlns:xsi=” xsi:schemaLocation=”"> <application-param> <param-name>webapp.encoding.default</param-name> <param-value>UTF-8</param-value> </application-param> <prefer-application-packages> <!--package-name>com.mycompany.util.*</package-name--> </prefer-application-packages> </weblogic-application>

    Note for DoubleIt there are presently no overrides declared under prefer-application-packages. However, if WebLogic reports classloading issues for your own web services, you may need to declare Java packages under this element to ensure those declared within the EAR are activated before any WebLogic-stored libraries are used.

  3. Update the POM files to accommodate the new ear module. In the trunk/pom.xml file, add the ear submodule:

    <modules> <module>service</module> <module>war</module> <module>ear</module> <module>client</module> </modules>

    Place the following pom.xml file in the ear folder:

    <project xmlns="" xmlns:xsi="" xsi:schemaLocation=""> <modelVersion>4.0.0</modelVersion> <parent> <groupId></groupId> <artifactId>basic-doubleit</artifactId> <version>1.0-SNAPSHOT</version> </parent> <artifactId>service-ear</artifactId> <name>EAR file for WebServiceSample</name> <packaging>ear</packaging> <dependencies> <dependency> <groupId></groupId> <artifactId>service-war</artifactId> <version>1.0-SNAPSHOT</version> <type>war</type> </dependency> <dependency> <groupId></groupId> <artifactId>service-bundle</artifactId> <version>1.0-SNAPSHOT</version> </dependency> </dependencies> <build> <defaultGoal>package</defaultGoal> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-ear-plugin</artifactId> <version>2.6</version> <configuration> <!-- Places jars in a lib subdirectory of the EAR (for readability) --> <defaultJavaBundleDir>lib/</defaultJavaBundleDir> <modules> <webModule> <groupId></groupId> <artifactId>service-war</artifactId> <contextRoot>doubleit</contextRoot> </webModule> </modules> </configuration> </plugin> </plugins> </build> </project>

    Note that service-war already has a dependency on service-bundle, but for some reason I couldn't get transitive dependencies to work with the maven-ear-plugin, so I explicitly listed service-bundle as a dependency in this POM file.

    Finally, in the service-war's POM, the WAR-building process needs to be modified to no longer copy the JARs into the WEB-INF/lib directory, as explained here. (Maven's ear plugin automatically copies dependencies to the EAR, even if they are already in the WAR's WEB-INF/lib directory. Removing them from the WEB-INF/lib directory therefore prevents duplication of JARs.) Modify the war submodule's maven-war-plugin configuration to the following: <build> ... <plugins> <plugin> <artifactId>maven-war-plugin</artifactId> <version>2.1.1</version> <configuration> <packagingExcludes>WEB-INF/lib/*.jar</packagingExcludes> <webXml>src/main/webapp/WEB-INF/web.xml</webXml> <webResources> <resource> <directory>../service/src/main/resources</directory> <targetPath>WEB-INF/wsdl</targetPath> <includes> <include>*.wsdl</include> </includes> </resource> </webResources> <archive> <manifest> <addClasspath>true</addClasspath> <classpathPrefix>lib/</classpathPrefix> </manifest> </archive> </configuration> </plugin> ... </plugins> ... </build>

  4. Update the soap:address URL in the WSDL file. The SOAP client relies on this address when making the web service call. In the doubleit.wsdl file, update the soap:address in the wsdl:service section to http://localhost:7001/doubleit/services/doubleit or similar (depending on your WebLogic HTTP port configuration.) Alternatively you can have the SOAP client route to the WebLogic URL by setting the ENDPOINT_ADDRESS_PROPERTY as shown in the SOAP client tutorial.

  5. Create the EAR. From the command prompt within the project base directory, enter mvn clean install. Once done, the EAR file to be uploaded to WebLogic will be located in the ear/target directory.

  6. Import the EAR into WebLogic Console and activate it. This process is the same as for any other EAR or WAR import. Make sure you can see the service WSDL at http://localhost:7001/doubleit/services/doubleit?wsdl before proceeding.

  7. Confirm that the SOAP client can access the WebLogic-hosted web service. Run the client as described in Step #10 of the DoubleIt tutorial to make sure that SOAP calls are working properly.

Additional Resources


JAX-RS services using CXF and Karaf

Jean-Baptiste Onofré - Fri, 08/19/2011 - 22:28
Apache CXF provides a really great layer to implement JAX-RS services. Especially, it fully supports OSGi, including Blueprint. It means that you can very easily create and deploy your REST services in a Apache Karaf container. In this example, we will see how to list all Karaf features via a REST service. This exemple is [...]
Categories: Jean-Baptiste Onofré

Apache WSS4J 1.5.12 and 1.6.2 released

Colm O hEigeartaigh - Thu, 08/18/2011 - 15:21
Apache WSS4J 1.5.12 and 1.6.2 have been released.

WSS4J 1.5.12 is a bug-fix release, which fixes some problems relating to future-dated Timestamps, fixes a bug with deriving keys from UsernameTokens, and fixes a concurrency issue with EnvelopeIdResolver, amongst other things.

WSS4J 1.6.2 contains some enhancements for SAML Token creation, fixes a bug with deriving keys from UsernameTokens, adds initial support for the Kerberos Token Profile 1.1, and fixes some problems relating to signature verification in certain containers.
Categories: Colm O hEigeartaigh

SAML token creation in Apache WSS4J 1.6

Colm O hEigeartaigh - Tue, 08/16/2011 - 20:10
WSS4J 1.6 uses Opensaml2 to create and parse SAML Assertions. WSS4J ships with a library that wraps the Opensaml API to greatly simplify the process of creating a SAML Assertion. The user implements a CallbackHandler instance which must be able to handle a WSS4J SAMLCallback object. and set certain properties on this object. WSS4J then parses the properties that were set on the object and creates a SAML Assertion accordingly. In this blog post we will examine the process of creating a SAML Assertion by populating a SAMLCallback object in more detail.

1) Obtain a SAMLCallback object

First off, a SAMLCallback object must be obtained in the CallbackHandler implementation, e.g.:

if (callbacks[i] instanceof SAMLCallback) {
    SAMLCallback callback = (SAMLCallback) callbacks[i];

2) Set the SAML Version

The first thing to do is to set the desired SAML Version of the Assertion you want to create on the SAMLCallback object, e.g.:


This method takes an org.opensaml.common.SAMLVersion object. For normal purposes, it will be one of the following:
  • SAMLVersion.VERSION_11
  • SAMLVersion.VERSION_20
The default value in SAMLCallback is VERSION_11.

3) Set the Issuer

The next thing to do is to set the issuer (String) name of the token, e.g.:


4) Set the Subject

The next thing to do is to set the Subject of the Assertion. WSS4J defines a SubjectBean which encapsulates a SAML Subject. The Subject Name, NameQualifier, NameIDFormat and ConfirmationMethod Strings can be set on the SubjectBean instance. The NameIDFormat and ConfirmationMethod values that can be set are largely defined in the SAML1Constants and SAML2Constants classes. The default value for the SubjectBean NameIDFormat is SAML1Constants.NAMEID_FORMAT_UNSPECIFIED. Both constants classes contain the following values that can be used for the ConfirmationMethod value:
  •  SAML[1|2]Constants.CONF_BEARER
  •  SAML[1|2]Constants.CONF_HOLDER_KEY
In addition to this, WSS4J defines a KeyInfoBean that can be set on the SubjectBean, which represents a KeyInfo structure that will be embedded in a SAML Subject. There are a number of different ways to set the KeyInfo value:
  • A DOM element can be defined for a pre-existing KeyInfo element
  • A PublicKey object can be used
  • An X.509 Certificate can be used
For the latter two cases, the KeyInfoBean contains a CERT_IDENTIFIER enum which defines how the PublicKey or X.509 Certificate will be output. The following values can be configured:
  • X509_CERT: An X509Certificate element will be output
  • X509_ISSUER_SERIAL: An X509 IssuerSerial element will be output
  • KEY_VALUE: A KeyValue element will be output
The default value in the KeyInfoBean is X509_CERT. Here is a sample that shows how to create a SubjectBean:

SubjectBean subjectBean = new SubjectBean();
KeyInfoBean keyInfo = new KeyInfoBean();

Finally, it remains to store the SubjectBean instance in the SAMLCallback object. A SAML 2.0 Assertion contains a single Subject, and so for this case the SubjectBean instance can be set directly on the SAMLCallback, e.g.:


For a SAML 1.1 Assertion, the Subject can be in a SubjectStatement (in which case it can be set directly on the SAMLCallback), or it can be embedded in one of the other statements which we will cover next.

5) Create and set a Statement

WSS4J contains a number of beans to create Statements for SAML Assertions, that can be set on a SAMLCallback object. They can be used in either SAML 1.1 or SAML 2.0 Assertions, with the caveat that SubjectBean instances are not used with statements in SAML 2.0.

a) Attribute Statements

WSS4J contains an AttributeStatementBean for creating Attribute statements. This contains a SubjectBean (for the SAML 1.1 case), and a list of AttributeBean objects. An attribute simple name, qualified name, and name format Strings can be set on the AttributeBean, as well as a list of attribute value Strings. Here is an example of creating and adding an AttributeStatement to a SAMLCallback object:

AttributeStatementBean attrBean = new AttributeStatementBean();
AttributeBean attributeBean = new AttributeBean();

b) Authentication Statements

WSS4J contains an AuthenticationStatementBean for creating Authentication statements. For SAML 1.1 a SubjectBean instance can be set on this object. In addition to this, an authentication instant and authentication method can be set, as well as a SubjectLocalityBean object and a session index String. Various authentication method Strings are defined in the SAML1Constants and SAML2Constants given above. Here is an example:

AuthenticationStatementBean authBean = new AuthenticationStatementBean();
SubjectLocalityBean subjectLocality = new SubjectLocalityBean();
authBean.setAuthenticationMethod("Password");     callback.setAuthenticationStatementData(Collections.singletonList(authBean));

c) Authorization Decision Statements

WSS4J contains an AuthDecisionStatementBean for creating Authorization Decision Statements. For SAML 1.1 a SubjectBean instance can be set on this object. A Decision enum can be set (PERMIT, INDETERMINATE, DENY), as well as a resource String, evidence Object, and a list of ActionBeans, which in turn contain an action namespace and action contents. Here is an example:

AuthDecisionStatementBean authzBean = new AuthDecisionStatementBean();
ActionBean actionBean = new ActionBean();
authzBean.setResource(resource);  callback.setAuthDecisionStatementData(Collections.singletonList(authzBean));
6) Create a Conditions object

Finally, a ConditionsBean object can be used to specify a set of Conditions on the SAML Assertion. This is optional, as by default a Conditions element will be generated with a NotBefore value of the present instant and a NotOnOrAfter value corresponding to 5 minutes into the future. This can be changed by creating a ConditionsBean and specifying either "notBefore" and "notAfter" dates, or else a token period in minutes in which the token is valid. It is also possible to specify an audience restriction URI on the ConditionsBean object. Here is an example:

ConditionsBean conditions = new ConditionsBean();

For some examples of CallbackHandlers used to create SAML Assertions, check out the following CallbackHandlers used in the WSS4J unit tests - SAML1AuthnHOKHandler, SAML1CallbackHandler and SAML2CallbackHandler.
Categories: Colm O hEigeartaigh

WS-Trust 1.4 support in CXF

Colm O hEigeartaigh - Mon, 08/15/2011 - 17:43
Apache CXF has had support for sending a WS-Trust 1.4 ActAs element as part of a RequestSecurityToken call to a Security Token Service (STS) since the 2.2.10 release. To quote from the WS-Trust 1.4 specification:
This OTPIONAL (sic) element indicates that the requested token is expected to contain information about the identity represented by the content of this element and the token requestor intends to use the returned token to act as this identity. The identity that the requestor wants to act-as is specified by placing a security token or <wsse:SecurityTokenReference> element within the <wst:ActAs> element.The object to be placed in an ActAs element can be set by the SecurityConstants tag "STS_TOKEN_ACT_AS" on the Message properties. Prior to Apache CXF 2.4.1 the ActAs object could either be an XML String or else a DOM Element. See the following CXF wiki page for more information.

Several enhancements were made in CXF 2.4.1 as part of this JIRA. First of all, support was added for OnBehalfOf. To quote from the spec again:
This OPTIONAL element indicates that the requestor is making the request on behalf of another.  The identity on whose behalf the request is being made is specified by placing a security token, <wsse:SecurityTokenReference> element, or <wsa:EndpointReference> element within the <wst:OnBehalfOf> element. The requestor MAY provide proof of possession of the key associated with the OnBehalfOf identity by including a signature in the RST security header generated using the OnBehalfOf token that signs the primary signature of the RST (i.e. endorsing supporting token concept from WS-SecurityPolicy). Additional signed supporting tokens describing the OnBehalfOf context MAY also be included within the RST security header.The object to be placed in an OnBehalfOf element can be set by the SecurityConstants tag "STS_TOKEN_ON_BEHALF_OF" on the Message properties. Similar to ActAs, this object can be an XML String or a DOM Element. In addition to this, the object for both ActAs and OnBehalfOf can now be a CallbackHandler instance. The CallbackHandler implementation must be able to process a DelegationCallback object, which has access to the current CXF Message, and returns a DOM Element to the STSClient for insertion into either ActAs or OnBehalfOf.

Two sample CallbackHandler implementations are shipped with CXF 2.4.1 that can be used for either OnBehalfOf or ActAs. The ReceivedTokenCallbackHandler obtains the previously received message from the current message property of the DelegationCallback object, and extracts a token that has been received in that message (SAML Token/UsernameToken/BinarySecurityToken). This token is then used as the delegation token. This CallbackHandler implementation is useful as part of an WS-Trust intermediary scenario. Secondly, the WSSUsernameCallbackHandler obtains a username via the jax-ws property "ws-security.username" (SecurityConstants.USERNAME), and creates a wsse:UsernameToken (with no password) to be used as the delegation token.
Categories: Colm O hEigeartaigh

This Week's Links (14 August 2011)

Glen Mazza - Mon, 08/15/2011 - 04:22

Use a &#8220;remote&#8221; EJB in Camel routes

Jean-Baptiste Onofré - Tue, 08/09/2011 - 20:18
Introduction You have an existing application, let say developed using J2EE, including EJB (Session). The application is running into a J2EE application server like JBoss, WebSphere or Weblogic. This application “exposes” EJBs to perform some business services. Now, you can to use these “remote” EJBs into Camel routes. Context We want to “expose” the EJB [...]
Categories: Jean-Baptiste Onofré

Apache Karaf Cellar 2.2.2 release

Jean-Baptiste Onofré - Mon, 08/08/2011 - 08:20
What’s new Quite one month ago, we released Karaf Cellar 2.2.1, the first “official” release of the Karaf clustering sub-project. This new Karaf Cellar 2.2.2 release includes bug fixes, especially one bug was a blocker as it was not possible to install Cellar on a Karaf instance running on Equinox OSGi framework. But, it’s not [...]
Categories: Jean-Baptiste Onofré

This Week's Links (7 August 2011)

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

Web Services:



Video: Talend Service Factory JAX-RS Advanced Example

Glen Mazza - Thu, 08/04/2011 - 14:11

I created a video for the JAX-RS Advanced Example provided with the free and open source Talend Service Factory. The video first shows how to download and install Talend Service Factory and its examples. Next covered is building and deploying this RESTful service in the Talend Service Factory OSGi container and making calls to that service using a provided REST client. Finally, we look into the Mavenized architecture of the REST service and important aspects of the source code. Enjoy!


This Week's Links (31 July 2011)

Glen Mazza - Sun, 07/31/2011 - 13:00

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 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 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 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.


Web Services Links (24 July 2011)

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

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="" xmlns:xsi="" xsi:schemaLocation=""> <modelVersion>4.0.0</modelVersion> <parent> <groupId></groupId> <artifactId>basic-doubleit</artifactId> <version>1.0-SNAPSHOT</version> </parent> <artifactId>service-bundle</artifactId> <name>Web Service Provider</name> <packaging>jar</packaging> <url></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: --> <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:

  • package service; import javax.jws.WebService; import javax.jws.WebMethod; @WebService public interface DoubleItPortType { public int doubleIt(int numberToDouble); } package service; import javax.jws.WebService; @WebService(targetNamespace = "", 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; import; import; import service.DoubleItPortType; public class WSClient { private static final QName SERVICE_NAME = new QName("", "DoubleItService"); private static final QName PORT_NAME = new QName("", "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


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: 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:
  2. Installation and initial configuration of the Talend Administration Center for Talend ESB:
  3. How to start Talend ESB Studio, and short overview of its available perspectives:
  4. Creating a simple Data Service Provider and Data Service Consumer, and running them in Talend ESB Studio:
  5. Deploying and running data services created in Talend ESB Studio within the Talend ESB Runtime:

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="" xmlns:xsi="" xsi:schemaLocation=""> <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> </argument--> <!-- Uncomment below for debugging with CXF. --> <!--argument> -Djava.util.logging.config.file=${env.CXF_HOME}/etc/ </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 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; 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();[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: Category: Cameras & Photo:Digital Cameras Item ID: 260615184611 URL: Category: Consumer Electronics:Gadgets:Surveillance:Security Systems Item ID: 180684987751 URL: ...several more items...


  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.



Subscribe to Talend Community Coders aggregator