Friday, January 20, 2006

From the ministry of confusing error messages

When JBoss says this:

Caused by: java.lang.IllegalArgumentException: URL cannot be null
at org.jboss.webservice.metadata.jaxrpcmapping.JavaWsdlMappingFactory.parse(JavaWsdlMappingFactory.java:55)

it may mean (well, it did in my case) that you've accidentally mis-typed the name of jaxrpc-mapping.xml. I guess the error arises whenever files referenced by webservices.xml don't exactly match the actual file names. A reasonable problem, but rather an opaque error message.

Tutorials good, understanding better

I'm working with web-services and with J2EE at present, two technologies that have a bewildering collection of components and configuration options (and configuration descriptors) by themselves. The Cartesian product of this complexity is, well, you can imagine. All is not lost though: various good souls have put together on-line tutorials (example) that show you, step-by-step, how to deploy a particular flavour of web service (say doc/lit) on a particular flavour of J2EE container (say, JBoss). Well and good, and a collective "thank-you" to all of those people. The problem I find, however, is that the tutorial gets a result (you can deploy the sample order-processing service and invoke it), but they don't help you understand the underlying technology. "Do this in webservices.xml" is all very well if you want to do the same thing in your actual code, but if you need something a bit different there's not enough depth in a walk-this-way tutorial. Actually, a reference to the specs would probably suffice in most cases. So, case in point (should I ever need it again!), webservices.xml is actually defined in JSR-000109.

Friday, January 06, 2006

JBoss Eclipse IDE - XDoclet not working

The time has come for me to get serious about learning J2EE. I've started on a new project, and the code is going to run in JBoss. So naturally, I've spent some time looking at options for tooling up Eclipse to cope with the demands of JBoss developing. First port of call was the Eclipse Web Tools Platform (WTP), which has just gone to release 1.0. There's no update URL yet (being fixed), so you have to download a mega-archive with Eclipse 3.1.1 and all the plugins. Then you have to spend time getting that to look like your old version of Eclipse, though exporting and and re-importing preferences helps. You still have to re-install your other plugins though (e.g. the very handy AnyEdit). Sigh. However, having installed it, there's a dearth of decent documentation. I tried working through the tutorial, but it was written for version 0.7 and most of the tools have changed. Still, I got to the point where I had a deployable JSP, published it to the running server instance and .... nothing. Deploying a WAR directly to JBoss with Ant works fine, but publishing from WTP fails silently. Since I don't have a clear conceptual model of what WTP is supposed to do - and the documentation doesn't help - I can't diagnose what went wrong. Spent some time fiddling, posted to their forum, then gave up around 01:30. If I ever find out what should have happened, I'll post a follow-up.

In the meantime, I've switched to JBoss's own JBoss Eclipse IDE. This is available as an Eclipse update URL. So, did that, first getting a clean new install of Eclipse 3.1.1. Fired that up, went to look at the HTML editor, and I get a bunch of spurious warnings (e.g. unrecognised HTML entities on properly escaped URL strings). This looks like cross-talk with previously installed HTML editors, so I removed my ~/workspace directory (where a lot of the local Eclipse settings are stored). Try again, this time all is working well. Spend more time getting Eclipse working how I like it (maybe I should educate myself to like the defaults, but currently I dont!). Fine. Now work through the tutorial from the JBoss web site. All seems well, except that when I run the XDoclet task, nothing visible happens. Checking the error log, there's a message:

Error logged from Ant UI:
java.net.SocketTimeoutException: Accept timed out

Like Bug 102463, I fixed this by resetting ANT HOME in the preferences dialog, which was pointing (bizarrely) to /usr/share/eclipse. I reset it to point to the org.apache.ant_1.6.5 subdirectory in the plugins directory of my local copy of Eclipse. After restarting Eclipse, XDoclet ran correctly.

Why is this stuff so painful?

del.icio.us: , , , .