This (unimaginatively titled) post explains how to set up remote debugging for Tomcat6 running as a Windows service using Eclipse and first, why you might want to.

Why remote debug?

Once an application grows over a certain size it becomes more difficult to work out what’s going on from watching its behaviour – e.g. error messages and stack traces. This is equally true for small but layered or componentised applications (and doubly true for large layered and componentised applications!).

One approach is to add log statements outputting debug information like variable names, loop counter statuses, null checks, but this quickly become more time-consuming than it’s worth, and being able to debug in the IDE gives you more control and ultimately saves a lot of time.

You might not believe me, but try a few rounds of entering log statements and restarting and then we’ll talk. If you’re not even doing that and entering System.out.println then shame on you!

How to set it up for Tomcat6/Eclipse

This article covers setting it up for Tomcat6 only because it’s slightly different. There are undoubtedly resources out there for your favourite web server / IDE combination so take a look.

In order to remotely debug the IDE needs to connect to another port where your app server is running (another meaning one than the port on which it accepts HTTP connections).

There are two parts to making this happen:

1. Telling the JVM on the web server which port to use for remote debugging
2. Telling your IDE which host and port to listen to

Tomcat6 is usually set up as a service on Windows and that makes setting the JVM arguments a little more complicated.

1. Open a command prompt in your /bin folder, e.g. “C:\Program Files\Apache Software Foundation\Tomcat 6.0\bin”
2. Use the tomcat6.exe utility to update the existing Tomcat6 service to add the JVM arguments. The arguments begin with -X and are separated by semi-colons.
   

   tomcat6 //US// —JvmOptions -Xdebug; -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n

The first argument tells the JVM to remotely debug and the second to accept a socket connection on port 8000. You don’t have to choose this port, any sensible free port will do.

That’s the web server set up. Now you need to set up Eclipse.

1. Go to Run>Debug Configurations and click the icon at the top of that screen to create a new one
2. Enter the host (in the picture I’m running my server locally hence localhost) and the port that you configured it on.

That’s all the set up. Now you just need to start the web server, set a breakpoint (e.g. in your login.jsp) and navigate to the login page on your development server. You should see your breakpoint hit.

Good luck!

I’m currently working on a client project where we’re making web service calls via JAX-RPC. Web Services are hugely important and useful but I can’t be the only person to think they’re a royal pain to develop and deploy!

If you’re using Apache Axis then there are some inbuilt tools that can help work out what’s going wrong when things go wrong. The most useful is tcpmon which acts as an “app-in-the-middle” and displays your SOAP request and response.

Here’s a quick how-to in setting up tcpmon in order to intercept your development web services calls and responses. Once you start using it the rest is pretty obvious but I’ve also included some screenshots of the input and output just so you can see.

The instructions assume Windows but replace the command prompts and environment variables with the usual in *nix and it all should work the same.

1. Open a command prompt and set the Java classpath to pick up the Axis classes (tcpmon is bundled with them)
2. set CLASSPATH=CLASSPATH;[my axis classpath]/wsif.jar;[my axis classpath]/axis-1.4.jar;[my axis classpath]/axis-ant-1.4.jar;[my axis classpath]/commons-logging-1.0.4.jar;[my axis classpath]/commons-discovery-0.2.jar;[my axis classpath]/wsdl4j-1.5.1.jar
3. Start tcpmon java org.apache.axis.utils.tcpmon
4. Enter the port where you want to run tcpmon (in the example below I use 1976 but check with netstat to find a free port)
5. Make the webservice call from your test client (the code snippet below is from a JUnit test method)

	// Note that the port is the tcpmon port and it will be forwarded to the web service port
	String endpoint = "http://localhost:1976/axis/services/PortingPort";

	Service service = new Service();
	Call call = (Call) service.createCall();

	// Prepare the call for the Web service
	call.setTargetEndpointAddress(new java.net.URL(endpoint));
	call.setOperationName("myService");
	MyParameterRequestType por = new MyParameterRequestType();
	por.setGreeting("Hello");
	call.addParameter("requestParam",new QName("http://mywsdl.endpoint.for.service/Service"),ParameterMode.IN);
	call.setReturnType(new QName("myParameterResponse"));
	call.invoke(new Object[] {por});

Below is the tcpmon “console” where you set the port that tcpmon listen on.

… and this is the request and response intercepted by tcpmon after making the test call