Tag: debugging

how to fix Java WebStart on MacOSX 10.5.7

I don’t know when this broke – maybe around the time Safari 4 was released? Anyway, Java WebStart stopped working. Downloading a .jnlp file and doubleclicking it brought up an editor (Dashcode) rather than the application launched via Java WebStart. I tried using Spotlight to find “Java WebStart” so I could manually launch the app. But nothing was found. WTF?

Apparently, the solution, of course, is to navigate in the Finder to /System/Library/CoreServices and click on Java WebStart.app – an entirely intuitive and obvious solution. This triggers some hidden magic to somehow restore access to JWS. Who knows. It works after doing this.

Debugging WebObjects

I got the chance to play with debugging a running WebObjects app today, with the added fun of having a roomful of 20 users of the app taking turns to mention “did you know that [X|Y|Z] isn’t working?”

Long story short, if you need to get the status of threads of a running WebObjects app, jdb provides some great tools. I have only scratched the surface of it, thanks entirely to the great intro document by Andrew Lindesay. (Andrew recently moved his website to .Mac from some New Zealand host, so I’m linking to help throw some Google Juice his way so others can find his article)

I’ve put a wikified crib sheet together to make it easier to get set up.

I got the chance to play with debugging a running WebObjects app today, with the added fun of having a roomful of 20 users of the app taking turns to mention “did you know that [X|Y|Z] isn’t working?”

Long story short, if you need to get the status of threads of a running WebObjects app, jdb provides some great tools. I have only scratched the surface of it, thanks entirely to the great intro document by Andrew Lindesay. (Andrew recently moved his website to .Mac from some New Zealand host, so I’m linking to help throw some Google Juice his way so others can find his article)

I’ve put a wikified crib sheet together to make it easier to get set up.

Fun with jGenerator

We’re using jGenerator for the Pachyderm project – to replace the abandoned Macromedia Generator product – for wrapping images in .swf files for display within Pachyderm presentations. The .swf files provide value-add stuff like “tombstone” data, and a lightweight, unobtrusive form of DRM.

However, jGenerator has been rather neglected for 3 years now, and as a result it’s starting to show cobwebs etc… Remember my friend Murphy? Largely a result of these cobwebs.

Today, days after we thought we nuked the jGenerator problem, it came back in full force. Building presentations would occasionally hang (sometimes not reliably, or sometimes very reliably). We tracked down the problem thanks to the handy dandy java debugger jdb (handy document on using jdb in a running WebObjects app), and it was the result of jGenerator using java.awt.Rectangle classes rather than java.awt.geom.Rectangle2D.

The methods had been altered to use Rectangle2D in the signatures, but were actually passing around Rectangle objects instead. This apparently causes problems on MacOSX and other Unix-like systems, as was discovered by the OpenLaszlo folks. They had to start their own fork of jGenerator 2.2 to fix this (and potentially other) problems. We just did the same.

We had another round of Team Programming at a Distance – the three of us brainstorming and hacking and researching. That is soooo much more fun and rewarding than copying and pasting…

We’re using jGenerator for the Pachyderm project – to replace the abandoned Macromedia Generator product – for wrapping images in .swf files for display within Pachyderm presentations. The .swf files provide value-add stuff like “tombstone” data, and a lightweight, unobtrusive form of DRM.

However, jGenerator has been rather neglected for 3 years now, and as a result it’s starting to show cobwebs etc… Remember my friend Murphy? Largely a result of these cobwebs.

Today, days after we thought we nuked the jGenerator problem, it came back in full force. Building presentations would occasionally hang (sometimes not reliably, or sometimes very reliably). We tracked down the problem thanks to the handy dandy java debugger jdb (handy document on using jdb in a running WebObjects app), and it was the result of jGenerator using java.awt.Rectangle classes rather than java.awt.geom.Rectangle2D.

The methods had been altered to use Rectangle2D in the signatures, but were actually passing around Rectangle objects instead. This apparently causes problems on MacOSX and other Unix-like systems, as was discovered by the OpenLaszlo folks. They had to start their own fork of jGenerator 2.2 to fix this (and potentially other) problems. We just did the same.

We had another round of Team Programming at a Distance – the three of us brainstorming and hacking and researching. That is soooo much more fun and rewarding than copying and pasting…

Murphy: 1, D’Arcy: 1

After what felt like a very long weekend of debugging jGenerator, I finally figured out what was going wrong, and how to fix it. It didn’t make sense at all, which is why I didn’t pursue that line of investigation earlier. The library worked fine before. It hadn’t changed. Then it didn’t work. I was figuring that meant something outside of the library had changed, and had borked something used by jGenerator.

Whatever the cause, I wound up using a java decompiler (jad) to figure out exactly where the problem was, while comparing to the versions of available jGenerator source code. I removed what appeared to be the offending line (calling Log.logRB() – which is a utility log method within jGenerator), and recompiled a fresh copy of jgen.jar using the Ant build script.

Deployed that sucker, restarted the Mavericks instance of the Pachyderm authoring app, and cést voila! I had it working early this morning, then published fresh copies of all of the Mavericks sections for review. *touches wood* It’s working great now!

So… in the future, when debugging something that isn’t behaving as expected… throw away all assumptions – no matter how “sure” you are about something, test and verify each and every line of investigation.

OK. Murphy, you can go to hell now…

After what felt like a very long weekend of debugging jGenerator, I finally figured out what was going wrong, and how to fix it. It didn’t make sense at all, which is why I didn’t pursue that line of investigation earlier. The library worked fine before. It hadn’t changed. Then it didn’t work. I was figuring that meant something outside of the library had changed, and had borked something used by jGenerator.

Whatever the cause, I wound up using a java decompiler (jad) to figure out exactly where the problem was, while comparing to the versions of available jGenerator source code. I removed what appeared to be the offending line (calling Log.logRB() – which is a utility log method within jGenerator), and recompiled a fresh copy of jgen.jar using the Ant build script.

Deployed that sucker, restarted the Mavericks instance of the Pachyderm authoring app, and cést voila! I had it working early this morning, then published fresh copies of all of the Mavericks sections for review. *touches wood* It’s working great now!

So… in the future, when debugging something that isn’t behaving as expected… throw away all assumptions – no matter how “sure” you are about something, test and verify each and every line of investigation.

OK. Murphy, you can go to hell now…