Page History

{code

}
import org.apache.cxf.feature.Features;

@javax.jws.WebService(portName = "MyWebServicePort", serviceName = "MyWebService", ...)
@Features(features = "org.apache.cxf.feature.LoggingFeature")        
public class MyWebServicePortTypeImpl implements MyWebServicePortType {
{code}

or (equivalent)

{code

}
import org.apache.cxf.interceptor.InInterceptors;
import org.apache.cxf.interceptor.OutInterceptors;

@javax.jws.WebService(portName = "WebServicePort", serviceName = "WebServiceService", ...)
@InInterceptors(interceptors = "org.apache.cxf.interceptor.LoggingInInterceptor")
@OutInterceptors(interceptors = "org.apache.cxf.interceptor.LoggingOutInterceptor")
public class WebServicePortTypeImpl implements WebServicePortType {
{code}


For programmatic client-side logging, the following code snippet can be used as an example:

{code

}
import org.apache.cxf.endpoint.Client;
import org.apache.cxf.frontend.ClientProxy;
import org.apache.cxf.interceptor.LoggingInInterceptor;
import org.apache.cxf.interceptor.LoggingOutInterceptor;

public class WSClient {
    public static void main (String[] args) {
        MyService ws = new MyService();
        MyPortType port = ws.getPort();
        
        Client client = ClientProxy.getClient(port);
        client.getInInterceptors().add(new LoggingInInterceptor());
        client.getOutInterceptors().add(new LoggingOutInterceptor()); 
        
        // make WS calls...

{code

:xml

}
<target name="runClient">
   <java classname="client.WSClient" fork="true">	    	
      <classpath>
         <pathelement location="${build.classes.dir}"/>
         <fileset dir="${env.CXF_HOME}/lib">
            <include name="*.jar"/>
         </fileset>
      </classpath>
      <jvmarg value="-Djava.util.logging.config.file=/usr/myclientapp/logging.properties"/>
   </java>
</target>

{code}

h2. Using Log4j Instead of java.util.logging

 

As noted above, CXF uses the {{java.util.logging}} package by default. But it is possible to switch CXF to instead use [Log4J|http://logging.apache.org/log4j/]. This is achieved through the use of configuration files. There are two options to bootstrapping CXF logging and each is listed below:

 

* Add the following system property to the classpath from which CXF is initialized:

{code}

* Add the file {{META-INF/cxf/org.apache.cxf.Logger}} to the classpath and make sure it contains the following content:

{code}

h2. Using SLF4J Instead of java.util.logging (since 2.2.8)

As noted above, CXF uses the {{java.util.logging}} package by default. But it is possible to switch CXF to instead use [SLF4J|http://www.slf4j.org/]. This is achieved through the use of configuration files. There are two options to bootstrapping CXF logging and each is listed below:

 

* Add the following system property to the classpath from which CXF is initialized:

{code}

* Add the file {{META-INF/cxf/org.apache.cxf.Logger}} to the classpath and make sure it contains the following content:

{code}

h1. Debugging Tools

h2. Eclipse IDE

See this [blog entry|http://www.jroller.com/gmazza/entry/eclipse_debug_web_services] for information on debugging web services using Eclipse.  Note this is primarily for tracing/debugging source code; you will probably still want to use one of the tools below to capture network traffic, view SOAP requests and responses, etc.

h2. NetBeans IDE
NetBeans include a [debugger|http://www.netbeans.org/features/java/debugger.html], [profiler|http://www.netbeans.org/features/java/profiler.html] and an HTTP monitor that can assist in troubleshooting SOA applications.

h2. tcpmon and tcptrace
[tcpmon|http://tcpmon.dev.java.net] allows you to easily view messages as they go back and forth on the wire. The companion utility [tcptrace|http://www.tcptrace.org] can be used for analysis of the dump.

h2. WSMonitor
[WSMonitor|https://wsmonitor.dev.java.net/] in another option to Tcpmon with slightly more functionality.

h2. NetSniffer
[NetSniffer|http://www.miray.de/products/sat.netsniffer.html] makes it possible to track the network traffic between arbitrary devices within a LAN segment.

h2. Wireshark
[Wireshark|http://www.wireshark.org/], a network packet analyzer, is useful for following the routing of SOAP messages.  It can also help when you are getting an HTML error message from the server that your CXF client cannot normally process, by allowing you to see the non-SOAP error message.  See this [blog entry|http://www.jroller.com/gmazza/entry/soap_calls_over_wireshark] for more information.

h2. SOAP UI
[SOAP UI|http://soapui.org] can also be used for debugging. In addition to viewing messages, it allows you send messages and load test your services. It also has plugins for the [Eclipse IDE|http://soapui.org/IDE-Plugins/eclipse-plugin.html], [NetBeans IDE|http://www.soapui.org/IDE-Plugins/netbean.html] and [IntelliJ IDEA|http://www.soapui.org/IDE-Plugins/intellij.html].

h1. Helpful Tools and Utilities

h2. WSDL Viewer
[WSDL Viewer|http://tomi.vanek.sk/index.php?page=wsdl-viewer] is a small tool to visualize the web-service in a more intuitive way. 

h2. cURL
[cURL|http://curl.haxx.se/] is a command line tool for transferring data with URL syntax, supporting DICT, FILE, FTP, FTPS, GOPHER, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, POP3, POP3S, RTMP, RTSP, SCP, SFTP, SMTP, SMTPS, TELNET and TFTP. curl supports SSL certificates, HTTP POST, HTTP PUT, FTP uploading, HTTP form based upload, proxies, cookies, user+password authentication (Basic, Digest, NTLM, Negotiate, kerberos...), file transfer resume, proxy tunneling and a busload of other useful tricks. 

h2. Sonar
[Sonar|http://www.sonarsource.org/] is an open source quality management platform, dedicated to continuously analyze and measure source code quality, from the portfolio to the method. Here is [CXF on Sonar|http://nemo.sonarsource.org/project/index/117804].

h2. Fisheye
 [Fisheye|http://www.atlassian.com/software/fisheye/] provides a web interface for Subversion, Git, CVS, Perforce & ClearCase source control repositories. Here is [CXF on Fisheye|https://fisheye6.atlassian.com/browse/cxf].