Friday, May 27, 2005

Launch Jetty from Eclipse - solving "Unable to find a javac compiler"

I've not used Jetty for a little while, and in the interim I've upgraded my computer and switched to Linux. Needless to say, when I came to running Jetty to do some web service work this morning, it broke. Specifically, the symptom was that when I launched Jetty from Eclipse, using the Jetty launcher plugin, Axis would fail with a nasty error message:

HTTP ERROR: 500
Unable to compile class for JSP
RequestURI=/axis/index.jsp

The problem is that the front page for Axis has changed since I last used it: it's now internationalized, which is a good thing, but it uses JSP's to do the internationalizing. JSP's are compiled dynamically, hence the need for a compiler. The HTTP error is accompanied by a stacktrace:

2005-05-27 21:35:54,421 ERROR [SocketListener0-1] compiler.Compiler (Compiler.java:412) - Javac exception 
Unable to find a javac compiler;
com.sun.tools.javac.Main is not on the classpath.
Perhaps JAVA_HOME does not point to the JDK
 at org.apache.tools.ant.taskdefs.compilers.CompilerAdapterFactory.getCompiler(CompilerAdapterFactory.java:105)
 at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:929)
 at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:758)
 at org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:407)
        .....

Do not listen to the tricksy error message. He is lying! Don't waste hours messing with your JAVA_HOME setting, wondering if the problem is related to using Java SDK 1.50 or 1.4.2, and switching back and forth between like a thing posessed. No, the simple answer is to add tools.jar (found in the lib directory of your Java SDK) to the classpath given to the Jetty instance. There's a tab to set the Jetty instance's classpath as part of the Jetty Launcher. Easy when you know how.

Update Dec 2006: Thanks for the nice comments and useful suggestions folks. I've now closed this entry to further comments.

Tuesday, May 24, 2005

New service

Nice line in today's Borowitz Report:

Elsewhere, Google announced that it was taking its search technology to a new level by introducing a new service that would enable users to find their car keys.
Seemed to nicely capture the zeitgeist to me!

Monday, May 23, 2005

Back to the USA

Just back from a week long visit to Philadelphia, at rather short notice. Lots of good food, reasonable beer and excellent semantic web conversation. Had dinner one night at Marrakesh on South Leithgow St (no web site, but there are contact details). Wonderful atmosphere in a tiny and really cosy place. The proprietor told us they were trying hard to recreate the feel of authentic Morroccan family dining. Worth visiting if you're in Philly for dinner. Good news: Philadelphia has free metropolitan wifi connectivity. Bad news: unless my wireless card is failing, the free network saturates pretty easily, and the bandwidth falls off to zero. I also had problems with the free wireless network in the Holiday Inn, which was otherwise a perfectly decent hotel. The barman was very generous when pouring measures!

Tuesday, May 10, 2005

Grokker Coolness

Danny Ayers spotted Grokker, a very cool search-results organisation tool with an online demo applet. Here's an example search. After a few minutes playing with it, I thought the results were good on precision (the returned hits were relevant, and the sorted categories were all nicely cohesive), but not quite so good on recall (percentage of relevant results returned). To be fair, it's self-described as only a demo at this point. I also wonder how, using the spatial layout metaphor, you browse multiple pages of results. Nonetheless, a very well executed demo. Kudos to the developers.

Saturday, May 07, 2005

When the open-source model breaks down

I have a fairly simple requirement: I want to write a long technical document, using DocBook as the markup language, and I want to conveniently cite references to other publications. And I want it to run on Linux. That's a simple requirement to state; I've discovered, to a reasonable standard of proof, that it's by no means easy to achieve. In fact, I've spent an immensely frustrating few days just trying - and failing - to cobble together a working solution.

There are tools out there. I've been looking mostly at two: refDB, and JReferences. Both are open-source reference managers, that import a variety of formats, and can produce DocBook marked-up bibliographies for a given input document. In theory. RefDB is the more polished and complete of the two tools. JReferences is a one-man effort that seems to be moribund for the last couple of years.

I actually got a fairly long way with refDB. I have installed the software, imported my references in RIS format, can query for particular refs and generate output in DocBook format. The tool I really want to use, however, would allow me to submit a document with <citation> elements in it, and the tool would comb my database for matching references and selectively generate formatted output. This process depends on having styles imported into refDB, and this is where the problems started. When I import a style, the refDB client goes into a busy-wait state, soaking 100% of the CPU and not terminating. I tried in verbose mode, to see what the problem might be, and got a meaningless cryptic three character error code. I surmised that there might be a problem with the libdbi database drivers, so I got the latest libdbi CVS head and tried to build it. After a bit of a false start, I can build the drivers but can't install them - the make install target breaks when installing the documentation, because it doesn't recognise the docbook schema for the SGML files, for wholly non-obvious reasons. It's at this point that the "many eyeballs make all bugs shallow" maxim falls apart. For my particular configuration, there is only my pair of eyes to look at the problem. At this point, I would gladly pay for either a licensed product, or a support contract, if I felt confident that I was going to get working functionality at the end of the day. The notion that I have the source so I can fix the problem myself doesn't work here: I have limited time to spare for the task of getting references into my document. There quickly comes a point when it's easier just to code the citatations by hand than to spend time grokking someone else's code and fixing problems.

The other tool I looked at briefly was JReferences. It's a Java program, so I felt comfortable that I could ascend the learning curve a bit more quickly if I needed to. It has the right features on paper: a RIS importer (among others) and DocBook exporter (among others), and a simple editor for viewing and updating stored references. So, task one: convert my RIS-formatted collection to BibTexML, which is JReferences' preferred internal format. There's a command-line utility to do just that. Run it, and it produces ... nothing. No output and no errors. OK, so it's a program that hasn't been touched for at least two years according to the CVS log at SourceForge. Maybe running it inside a Java debugger will reveal a simple fix. So, I get the source, drop it into Eclipse and .... and it won't compile. Not even close. There seems to be two different package layouts competing with each other. Lots of inconsistencies that Eclipse barfs on. Worse, many of the problems are incompatibilities with bibtexml.jar, which is only distributed in binary form that I can find. I can't imagine how this program ever worked properly. I can't see any test code at all. There's not actually that much code all told, and I'm fairly sure I could, if I wanted, fix it up.

But why bother? It would be significantly easier for me to start over with an empty project in Eclipse than spend time understanding, fixing, and extending the existing codebase. Open source, code re-use, and so on only helps if the code is functional, comprehensible and working. Lose that, and you have worse than nothing.

Tuesday, May 03, 2005

Enterprise integration as a cultural collaboration problem

Sean McGrath posted an interesting article on ITWorld: ITworld.com - Mediators and mediatees - Enterprise integration as an industrial relations problem. The basic premise is that IT systems embody a certain view of the world, and that where these differ - e.g. the world-view of the accountancy department is fundamentally different from the goods-in department - you have conflict. Apps don't interoperate because they're seeing the world differently, and hence (Sean proposes) enterprise application integration, or EAI, is essentially an industrial relations problem. It's a nice thought, and I'm not going to get all analytical about what is essentially a thinking-aloud exercise, but I don't agree.

The basic problem, is that different doesn't necessarily equal in conflict. I know that it sometimes can, and hence enlightened companies (including HP) are very keen on promoting a diversity agenda, seeing differences between people as something to celebrate and learn from. But Sean's industrial relations metaphor seems to me to assume that the putative accounting and goods-in apps are in conflict and in need of mediation, just because they see the world in a different light. I'm no student of industrial relations, but it seems to me that such problems generally arise when the goals of two groups, workers and management typically, are in conflict over some limited resource (such as productivity, or access to the corporate jacuzzi). I don't see how this applies to EAI.

I propose a different metaphor: EAI as a problem of building collaborations between two cultures. This weekend just past, my family and I attended my wife's cousin Adrian's wedding to his Chinese bride Chunli. It was a lovely ceremony, not least because of the way that Chinese and British influences were combined to make something that was different from a traditional wedding in either culture (assuming there is such a thing).

What does cultural collaboration require? Like Sean, I'm only thinking aloud here. It requires a some common ground, and a shared purpose. It requires each participant to bring some unique values, and to make space for the uniqueness of the other. True collaboration demands a delicate balance of yielding and non-yielding of control. And, I suspect, to really bring such a thing off requires a touch of artistry. It is often paying attention to the little details that make success inevitable.