For the past week I’ve been trying to write a Axis2 service that generates XML output that conforms to a set of XSD files.  The first challenge was to get the XSD files into a “Java friendly” format, which I solved by using XMLBeans. I’m new to XMLBeans but it was pretty easy to pick up and within an hour or so I had all of my XSD files converted to some nice Java JARs that gave me access to the XML entities as objects and let me quickly create the XML output I was looking for.  Given my initial success I figured it would be pretty easy to just insert the XMLBean generated JARs & code into my web service project, however every time I ran my code as part of my Axis2 webservice the output was missing xsi:type elements.

So at first I thought I’d done something wrong in XMLBeans with the XMLOptions, the JAR generation, or maybe even my XSD files, but after hours of trying different configurations and options my code was still dropping the xsi:type elements from my output.  To debug the problem, I figured I’d try writing a simple java command line program to see if I could debug the issue, but when I ran my code as a standard Java application the output was what I was expecting:

<?xml version=”1.0″ encoding=”UTF-8″?>
<c:BroadsoftDocument protocol=”OCI” xmlns:c=”C”>
<sessionId>000000001</sessionId>
<command xsi:type=”AuthenticationRequest” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”>
<userId>admin</userId></command>
</c:BroadsoftDocument>

However, when the exact same code was run under Axis2 & Tomcat in a servlet I was getting:

<?xml version=”1.0″ encoding=”UTF-8″?>
<c:BroadsoftDocument protocol=”OCI” xmlns:c=”C”>
<sessionId>000000001</sessionId>
<command>
<userId>admin</userId></command>
</c:BroadsoftDocument>

This of course isn’t valid – the xsi:type of the “command” element is stripped when the code is run under Axis2/Tomcat.

I then wrote a simple servlet application to remove Tomcat as a suspect and my hunch was confirmed – the corruption only happened when running the code as part of an Axis2 web service.

Having finally narrowed down the issue to Axis2, I did some googling for that and found an exact post that mentioned a CVS checkin to resolve xsi:type issues with Axis2: http://marc2.theaimsgroup.com/?l=axis-cvs&m=115946726426905&w=3

After reading the post and discovering the “ServiceTCCL” option I had my solution – adding “<parameter name=”ServiceTCCL”>composite</parameter>” to the services.xml of my Axis2 project everything started to work as expected.

So now with a solution at hand I can actually get down to writing some code – it’s just too bad I had to jump through so many hoops to get there!

axis, java, xmlbeans Hide