<addresses class="java.util.Arrays$ArrayList">
<a class="address-array">
<address>

It had to step through the code to see what was going on.

The key is in the subtlety of the type of the list that I was putting in there. Notice that actually its not an java.util.ArrayList its actually an inner class of the Arrays, called, happily $ArrayList, so I had been staring at it the whole time and not noticed.

When XStream serializes its doing the following:

        Class actualType = newObj.getClass();
        Class defaultType = mapper.defaultImplementationOf(fieldType);
        if (!actualType.equals(defaultType)) {
            String serializedClassName = mapper.serializedClass(actualType);
            if (!serializedClassName.equals(mapper.serializedClass(defaultType))) {
                String attributeName = mapper.aliasForSystemAttribute(“class”);
                if (attributeName != null) {
                    writer.addAttribute(attributeName, serializedClassName);
                 }
            }
        }

From version 1.3.1 – AbstractReflectionConverter:127

So its asking the mapper what the default implementation of the type is. The type in this case was java.util.List and the default implementation is of course java.util.ArrayList. It is not seeing java.util.Arrays$ArrayList as the same thing and so thinks it needs to specify it.

Now you might be asking, how come I have a strange inner class version of ArrayList ? Well the thing is, I thought I was being clever in the set up of my test data and im using:

       addresses = Arrays.asList(
                new AddressBuilder().addressType(“home”).streetAddress(“1 The street”).build(),
                new AddressBuilder().addressType(“work”).streetAddress(“2 The street”).build(),
                new AddressBuilder().addressType(“holiday”).streetAddress(“3 The street”).build()
        );

To set up my test data. asList does this:

 public static  List asList(T… a) {
	return new ArrayList(a);
    }
    private static class ArrayList extends AbstractList
	implements RandomAccess, java.io.Serializable
    {
        private static final long serialVersionUID = -2764017481108945198L;
	private Object[] a;

Where it uses its own implementation of ArrayList.

Phew, another fun couple of hours spent there.

The problem is that it is hiding what is really going on, which is that it could not match the namespace uri in the schema document to the one in my xml document.

The xml:

<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom"
      xmlns:h="http://some.custom.schema">

    <title>/v2/people/facebook.com/@self</title>
    <updated>2003-12-13T18:30:02Z</updated>

    <h:callId>b702ae86-b07f-4e2f-b49f-27d1a79b7783</h>
</feed>

The xsd

<xs:schema elementFormDefault="qualified"
                      targetNamespace="http://some.target.namespace.which.does.not.match"
                      xmlns="http://some.target.namespace.which.does.not.match"
                      xmlns:xs="http://www.w3.org/2001/XMLSchema">
</xs>

Check it.

hmmm – cant paste it in here – see attatched file!!

XSLT Transformation to Generate an XSD schema

Ok it was MUCH simpler than i thought of course! you simply type in the whole thing into the xslt and it just prints it out! so you dont need to use xs element at all doh!

xmlns:xs="http://www.w3.org/2001/XMLSchema">

When you create the document factory you have to tell it to become namespace aware :

static final String JAXP_SCHEMA_LANGUAGE =
“http://java.sun.com/xml/jaxp/properties/schemaLanguage”;

static final String W3C_XML_SCHEMA =
“http://www.w3.org/2001/XMLSchema”;
try {
factory.setAttribute(JAXP_SCHEMA_LANGUAGE, W3C_XML_SCHEMA);
}
catch (IllegalArgumentException x) {
// Happens if the parser does not support JAXP 1.2
throw new XMLValidationException(“Could not create validating XML Parser ” + x.getMessage(), x);
}

THis lets it understand, otherwise you get :

org.xml.sax.SAXParseException: Document is invalid: no grammar found.
org.xml.sax.SAXParseException: Document root element “EClaim_Message”, must match DOCTYPE root “null”.

THen you create a view onto that table which maps elements inside the XML blob to columns in the view, thus “expanding” out the xml to look like a normal table.

To do this you use the extract() method in oracle (see other posts) .

Now you want to filter the view based on nodes which are inside the xml data but oracle wont let you do it directly because the columns arent real columns.

SO

You need to include a unique key in the view – then you can do the select on the original table and JOIN the view to it! bit convoluted but it works! as long as there is a unique key of course – so you might have to design your xml table with this in mind but even if this is arbitrary it will still work.

here is an example :

SELECT tbview.* FROM TABLE_ONE tb, TABLE_ONE_VIEW tbview
WHERE
tbview.UNIQUE_ID=tb.UNIQUE_ID
AND
tb.XML_COLUMN.existsNode(‘/some/expath[with_test_node="TEST_2"]‘)=1;

Sweet!

WHERE tb.XML_COLUMN.existsNode(‘/some/xpath[with_test="Jeff"]‘)=1

have to use this “existsNode” the xpath can then do the filter – if you want to filter on the value of a node you do the above, otherwise use @ for attributes.