Improvments of Castor JAXB

First observation, it would be wise to switch the dependant version of the Castor XML from 1.3.2 to 1.3.3,
that would provide the support for the STaX and (javax.xml.transform) Source/Result.

I don't think this is a good idea because, after a new release other users won't be able to build until the new snapshot has been deployed in maven repository. Therefore we should only depend on the last public relase which is 1.3.2 at this time.

List of methods from (Un-)Marshaller that require implementation:

Marshaller:

• public < A extends XmlAdapter > A getAdapter(final Class < A > xmlAdapter)
• public AttachmentMarshaller getAttachmentMarshaller()
• public Node getNode(final Object node)
• public void marshal(final Object object, final XMLStreamWriter xmlStreamWriter)
• public void marshal(final Object object, final XMLEventWriter xmlEventWriter)
• public void setAdapter(final XmlAdapter arg0)
• public < A extends XmlAdapter > void setAdapter(final Class < A > arg0, final A arg1)
• public void setAttachmentMarshaller(final AttachmentMarshaller arg0)

Unmarshaller:

• public < A extends XmlAdapter > A getAdapter(final Class < A > arg0)
• public AttachmentUnmarshaller getAttachmentUnmarshaller()
• public ValidationEventHandler getEventHandler()
• public Schema getSchema()
• public UnmarshallerHandler getUnmarshallerHandler()
• public void setAdapter(final XmlAdapter xmlAdapter)
• public < A extends XmlAdapter > void setAdapter(final Class < A > type, final A xmlAdapter)
• public void setAttachmentUnmarshaller(final AttachmentUnmarshaller attachmentUnmarshaller)
• public void setEventHandler(final ValidationEventHandler validationEventHandler)
• public void setSchema(final Schema schema)
• public Object unmarshal(final XMLStreamReader xmlStreamReader)
• public Object unmarshal(final XMLEventReader xmlEventReader)
• public < T > JAXBElement < T > unmarshal(final Node node, final Class < T > type)
• public < T > JAXBElement < T > unmarshal(final Source node, final Class < T > type)
• public < T > JAXBElement < T > unmarshal(final XMLStreamReader xmlStreamReader, final Class < T > type)
• public < T > JAXBElement < T > unmarshal(final XMLEventReader xmlEventReader, final Class < T > type)

JAXBContext:

• public Validator createValidator() throws JAXBException
• public <T> Binder<T> createBinder(final Class<T> domType)
• public Binder<org.w3c.dom.Node> createBinder()
• public void generateSchema(final SchemaOutputResolver schemaOutputResolver)

Ok, Ralf good point.

I revised the current implementation of the (Un-)Marshaller class, doing some refactoring and implementating couple of methods from Unmarshaller:

Precisely:

• public Object unmarshal(final XMLStreamReader xmlStreamReader)
• public Object unmarshal(final XMLEventReader xmlEventReader)
• public < T > JAXBElement < T > unmarshal(final Node node, final Class < T > type)
• public < T > JAXBElement < T > unmarshal(final Source node, final Class < T > type)
• public < T > JAXBElement < T > unmarshal(final XMLStreamReader xmlStreamReader, final Class < T > type)
• public < T > JAXBElement < T > unmarshal(final XMLEventReader xmlEventReader, final Class < T > type)

I made changes in documentation.

Couple additional thoughts:

• I think if this is going to work as real provider then those JAXBContext#newInstance methods are useless, the user is not suppose to use the org.castor.jaxb classes directly. Instead I would introduce a CastorJAXBContextFactory which would be responsible for creating the JAXBContext. According to the api docs(http://jaxb.java.net/nonav/jaxb20-fcs/docs/api/index.html) a jaxb.properties file is required in each package that contains annotated classes.

• How about renaiming the classes into CastorMarshaller, CastorUnmarshaller, CastorJAXBContext, CastorJAXBIntrospector.

I wish to upgrade the test framework to JUnit 4.x, there for I already modified the existing test cases.

I will try to get those changes in one after one ... let's see how far I get.

JUnit and Castor dependencies upgraded.

Rest committed as well.

I revised the current implementation of the (Un-)Marshaller class, doing some refactoring and implementating couple of methods from Unmarshaller:

Great stuff. But rather than maintaining all your work progress in Jira pages, can I please ask you to create yet another Wiki page (similar to the page for the OXM stuff), and add all relevant information there, e.g. what still needs to be implemented and what has been done/finalized already.

How about renaiming the classes into CastorMarshaller, CastorUnmarshaller, CastorJAXBContext, CastorJAXBIntrospector

Yes, pretty please. Should make the JAXB code much more readable.

Instead I would introduce a CastorJAXBContextFactory which would be responsible for creating the JAXBContext

Feel free. I honestly have to admit that I need to start looking at the JAXB specs again .. .

Draft of the wiki page created -> http://docs.codehaus.org/display/CASTOR/Castor+JAXB

I think what really is required is a suite of functional tests that tests the individual features of the JAXB spec/API and its working (with respect of e.g. various annotation settings). E.g. verify that the use of @XmlElementWrapper together with @XmlElement works as designed.

I agree here and this is what I am trying to achieve.

I prepared next patch in which I have done the fallowing:

• modified the Castor version to 1.3.3-SNAPSHOT
• introduced CastorJAXBContextFactory for createing the JAXBContext
• renamed the Marshaller, Unmarshaller, JAXBContext and JAXBIntrospector
• introduced CastorUnmarshallerHandler

Tests for various marshall methods attached.

Had to change the setUp() method as follows to get things working (and comment out testMarshallWriterJAXBElement):

    @Before
    public void setUp() throws JAXBException {

        javax.xml.bind.JAXBContext context = org.castor.jaxb.JAXBContext.newInstance(Entity.class);
        marshaller = context.createMarshaller();
    }

Any idea why that seems to be working with you and not with me ?

The proper class should be loaded from jaxb.properties file.
I placed such file in src/test/java/org/castor/entities directory, it has a single entry, which is:
javax.xml.bind.context.factory=org.castor.jaxb.CastorJAXBContextFactory

But I tested that (on Win7 with Java 6) and I don't know how come the file is skipped.

Can I please ask you to re-attach the patch for CastorMarshallerTest after you have SVN UPed my commit ?

No problem, I will add the tests for CastorUnmarshaller by the way.

Great. Can I ask you a favour, pretty please. Can you please create sub-tasks for some of the packages you are working on, and attach patches there ? This task is getting rather long-ish ....

I was asking myself yesterday how to ago about testing (functionally) all the fatures of the JAXB specification. Take, for example, the @XmlAttribute annotation. Just focusing on the annotation itself (and its use) and the available 'name' property, there's at least a few variants here that need to be tested.

@XmlAttribute
private String name;

@XmlAttribute
private String complexName;

@XmlAttribute (name = "name2") 
private String name;

It is definitely possible to create (in this case) three POJOs, all configured accordingly, but this might get a bit tedious when we expand the scope. Any idea on this ?

The proper class should be loaded from jaxb.properties file.
I placed such file in src/test/java/org/castor/entities directory, it has a single entry, which is:
javax.xml.bind.context.factory=org.castor.jaxb.CastorJAXBContextFactory

Yes, I have seen that file, but for some reason that does not work for me. And I am on Win7 and Java 6 as well, in case that does make a difference.

In addition, can I ask you to create bugs/sub-tasks for all your findings from the Confluence page(s). E.g. the issue with the 'incorrect' XML naming definitely should be a traceable item.

Reason, why the tests failed, found. The solution was quite simple. I had to move the mentinoned file into the resources directory, then the tests seams to work. Patch attached.

Testsing will be a a non trivial issue in this case, but I don't see a simple solution that would give some posibility to tests that automaticily.

My idea for testsing was to do two things tests the interface of the classes, which I try to do in this moment - prepare a test for each method and see if dose at least work with simple cases and after that it would be the best thing to prepare seperate unit cases that tests concreate functionality, for example the annotation handling.

I had an idea to prepare a schema file (xsd) and add the xjc pluging which would generete the mapped classes in other to found out what actually works.

Patch for CastorUnmarshaller has been prepared.

How I see this farther:

• I want to remove the Marshaller, Unmarshaller, JAXBContext and JAXBIntrospector, but first I would have to deal with the tests.
• Add extra tests that shows how much of the JAXB annotations is supported.
• Implement the Marshaller properties support.
• Implement validation agains the schema in both marshaller and unmarshaller.
• Implement package registreation in JAXBContext.

There two things that currently I am not sure how to deal with: XmlAdapter class and AttachmentMarshaller/Unmarshaller the second thing won't be trivial without 'native' support from Castor.

I want to remove the Marshaller, Unmarshaller, JAXBContext and JAXBIntrospector, but first I would have to deal with the tests.

I guess that refers to to the classes for which you have already added their corresponding Castor- equivalents ?

Personally, I'd not look into Attachement* functionality for the time being, as I'd consider it to be the least important. Yes, we can have a go at this once everything else is in place.

Thanks Werner

I guess that refers to to the classes for which you have already added their corresponding Castor- equivalents ?

Yes, that is correct, but I had to first modify the existing tests.