Yes No Probably

Infuriating. They have deliberately left out one option (and the one I would probably tick): "Probably Not".

Oh FFS

All I want to do is extract a few 100MB of zip file to my Desktop, and here's what Windows tells me:



Why can't they bloody well fix this sort of moronicness?
Cf. this cartoon.

First time i've seen this...

Waitrose Sandwich

Am pleased to read that Waitrose don't use Waitrose-disapproved farms...

Prospect of whitby

Another sign

St catherines dock

JAX-WS service with JAXB

Things to remember:

1. JAX-WS uses JAXB 2.0 by default, so no need to choose from the myriad of OXM products that are around. Create JAXB 2.0-annotated classes using the xjc compiler - this takes XSDs and makes annotated Java objects out of them. Download the JAXB RI and run xjc, you should get sourcecode of classes which you can then use. If your data doesn't seem to be being serialized/deserialized, check that you've got valid JAXB annotations on it: I created a test class with a couple of fields, and was confused when I didn't get anything on the inbound object. But of course I'd forgotten the annotations - if they're not there JAXB won't try to do anything with it, so nothing will get in or out. If you're creating a test message class, maybe it's a better idea to create an XSD for it and then run it through the JAXB Binding Compiler (xjc)?

2. Be ultra-careful with namespaces: make sure your messages are consistently using the namespaces specified on the SOAP envelope and are defined as the same targetNamespace on the service methods. Especially if your JAXB-annotated objects are in a different namespace to the service methods themselves. You will need to specify both as attributes on the SOAP envelope, e.g.

<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:ns1="http://services.merlesystems.co.uk/"
xmlns:ns2="http://schemas.merlesystems.co.uk">
<env:Header />
<env:Body>
<ns1:testStructuredName>
<ns2:structuredName>
<ns2:forename>Lily</ns2:forename>
<ns2:surname>Allen</ns2:surname>
</ns2:structuredName>
</ns1:testStructuredName>
</env:Body>
</env:Envelope>

You can specify the namespaces on the elements themselves as well, but that gets quite verbose if you have a lot of elements, you can't see the wood for the trees.

3. Deploying the service is pretty easy using the Weblogic Workshop, it does all the spadework for you, as long as you want to deploy it on Weblogic... Creating a JAX-WS service with Axis2 seems a lot harder than it needs to be. The documentation is a bit random and I just couldn't get it to do what I hoped it would. Spring-WS promises to be easy too, as long as you don't have any problems downloading the Maven artifacts that it needs!

Bath abbey

Bracelet 2

H

Red rubber bands

Hudson on Weblogic

Hudson is a brilliant continuous integration tool, easier to configure than Cruise Control... but how to deploy it on Weblogic? When I tried it, it complained that the Ant version bundled with Weblogic 10g was incompatible with Hudson's.
Initially I tried giving the hudson.war a weblogic.xml file containing:

<weblogic-web-app xmlns="http://www.bea.com/ns/weblogic/weblogic-web-app">
<container-descriptor>
<prefer-web-inf-classes>true</prefer-web-inf-classes>
</container-descriptor>
</weblogic-web-app>


but it didn't seem to work for me, so I went with the suggestion in this useful post, which suggests wrapping the hudson.war in an EAR, and deploying that, with the classloader configured to prefer application packages for the org.apache.* classes.

So that got me up and running (merci Maxence!), but when I started trying to run builds for projects using Maven, I hit another problem. Under Weblogic, calling out to the bundled Maven agent seems to have a bug. See this post, which looks similar to my problem as it cannot access the Maven agent JAR using the zip: protocol - there are other posts knocking around for similar problems in JBoss and/or Tomcat, but no fix available yet.

Unable to get the native Hudson Maven integration working properly, I resorted to invoking the Maven command line interface from Hudson: create a script which cds to the folder containing the Maven project (as Hudson by default runs scripts from its workspace folder) and then does "CALL mvn clean install" to run your Maven installation. Then, from the Hudson web console, set your Hudson job up to run your script (again, relative to the workspace folder).

Pointless sign