## Monday, May 31, 2010

### Debugging Alfresco Tomcat with Eclipse

I am having trouble debugging Alfresco (a web app running on Tomcat) with Eclipse. For some reason I can’t access it in debugging mode. I am sure this is not anything specific to Alfresco; probably it is to do with either not having Tomcat set up correctly for debug mode or something environmental on my PC preventing Eclipse from connecting to Tomcat in debug mode.

I posted about this on the Alfresco forums (Debugging Alfresco Tomcat with Eclipse), but haven’t received any response as yet. So here is a detailed description of my problem.

I have the JPDA_TRANSPORT environment variable is set to dt_socket.

The JPDA_ADDRESS environment variable is set to 8000.

In Tomcat’s startup script (C:\Alfresco\tomcat\bin\startup.bat), I changed the line that invokes Catalina to include jpda:

call "%EXECUTABLE%" jpda start %CMD_LINE_ARGS%

When I start Tomcat and see the below messages in the console.

Listening for transport dt_socket at address: 8000
28/05/2010 1:44:42 PM org.apache.coyote.http11.Http11Protocol init
INFO: Initializing Coyote HTTP/1.1 on http-8080

I set up Eclipse debug config as per the screen shot below.

And when I attempt to start that debug configuration, I get the below error from Eclipse.

Error detail is below.

eclipse.buildId=2.3.1.201003091003-RELEASE
java.version=1.6.0_20
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_AU
Framework arguments:  -product com.springsource.sts.ide
Command-line arguments:  -os win32 -ws win32 -arch x86 -product com.springsource.sts.ide -clean -data D:\work\projects\JadeLynx\Alfresco-3.3

Error
Fri May 28 14:55:37 EST 2010
Failed to connect to remote VM. Connection refused.

java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:529)
at java.net.Socket.connect(Socket.java:478)
at java.net.Socket.<init>(Socket.java:375)
at java.net.Socket.<init>(Socket.java:189)
at org.eclipse.jdi.internal.connect.SocketTransportService\$2.run(SocketTransportService.java:136)
at java.lang.Thread.run(Thread.java:619)

I made sure Windows firewall was turned off.

I made sure Eclipse has no proxy information.

I did a netstat -an | grep -i listen to confirm port is being listened at. I guess it is:

TCP    0.0.0.0:8080           0.0.0.0:0              LISTENING

I tried the advice in this thread: Debugging Alfresco Tomcat with Eclipse .

Open Catalina.bat [C:\Alfresco\tomcat\bin], find “DEBUG_OPTS=” and add following line..
set DEBUG_OPTS= -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8000

I tried the advice in this thread too : Remote Debugging with Eclipse.

You may also add following line to your alfresco.sh and start the server
export JAVA_OPTS='-Xdebug -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=y'

All to no avail. So, how do I prove the server is really listening? Any other ideas would be more than welcome!

Further information: when the server has started, I see this on the console (before I even try to connect to the debugger):

CODE: SELECT ALL
31/05/2010 1:45:41 PM org.apache.coyote.http11.Http11Protocol start
INFO: Starting Coyote HTTP/1.1 on http-8080
31/05/2010 1:45:41 PM org.apache.catalina.startup.Catalina start
INFO: Server startup in 159453 ms
Debugger failed to attach: timeout during handshake

# Solved!

Talk about egg on my face! The debugging was working perfectly all along.. each time I tried, Eclipse "did nothing", which I thought was weird - so I tried again and got the error message. What I didn't realise is that Eclipse had started debugging the first time: I just didn't realise it because I am used to Eclipse saying "Shall I enter debug mode?"

What a relief. *whew* :)

## Wednesday, May 19, 2010

### Cygwin man: cannot open configuration file

I recently installed Cygwin anew, and found the below output when I ran a man command.

Bacon Lettuce and Tomatoe - ~/wd
Wed May 19 - 01:03 PM > man ls
Warning: cannot open configuration file /usr/share/misc/man.conf


This was followed by a lot of gibberish. Thankfully, Google saved the day, with this readlist.com post: Garbage man pages. The fix was simple, as below.

cp /etc/defaults/usr/share/misc/man.conf /usr/share/misc/man.conf

## Wednesday, May 12, 2010

### Setting persistence file for Eclipse Multi-Clipboard plugin

I have been using Bastian Bergerhoff's excellent Multi-Clipboard Eclipse plugin for a few years now. It is brilliant: you get a potentially unlimited number of clipboard buffers that you can copy/cut to or paste from. There is a handy view supplied to see the contents of all the buffers. There are customisable keyboard shortcuts for getting items into/out of the buffers: you can set your own shortcuts for copying/pasting to/from buffers 1 through 10.

You can even tell the plugin to persist the buffers to a file such that the buffer contents survive across Eclipse restarts. Do this by specifying a writable directory in the plugin's preferences: Window > Preferences > Multi Clipboard > Directory.

Thing is, for some reason on XP, even though I am a member of the Administrators group, every directory on my PC is some sort of Read-Only, as per the image below.

So whenever I attempt to click "OK" or "Apply" in the Multi-Clipboard preferences dialog after specifying a directory, I get a persistence error such as below. "The directory you selected can either not be read from or not be written to or both. Please select a readable and writable directory."

There is a way around this though. All I need to is edit the following file in my workspace: .metadata\.plugins\org.eclipse.core.runtime\.settings\de.babe.eclipse.plugins.MultiClipboard.prefs. I edit the  clipboardSavePathPreference line to specify a directory, for example see below.

clipboardSavePathPreference=D\:\\path\\to\\eclipse\\workspace

I restart Eclipse and all is well with the world once more (for now).