Possible bug in spring-oxm JAXB support

[routis]

I am trying to use the JAXB support of spring-oxm version 0.9.1 with the JAXB 2.0 implementation of Sun.

I believe that may be a bug in the JaxbMarshaller.afterPropertiesSet() method at line 112.

The call to unmarshaller.setValidating() is deprecated according to:

https://jaxb.dev.java.net/nonav/jaxb...dating(boolean)

and always throws the mentioned exception

[routis]

I created an issue

Link: http://opensource.atlassian.com/proj.../browse/SWS-22

[Arjen Poutsma]

I am trying to use the JAXB support of spring-oxm version 0.9.1 with the JAXB 2.0 implementation of Sun.

I believe that may be a bug in the JaxbMarshaller.afterPropertiesSet() method at line 112.

The call to unmarshaller.setValidating() is deprecated according to:

https://jaxb.dev.java.net/nonav/jaxb...dating(boolean)

and always throws the mentioned exception

Yep, that's a bug. Thanks for creating the JIRA issue, I will fix it soon.

The reason for this bug is quite obvious: I only tested it with JAXB 1.0, since JAXB 2.0 is not final yet. That said, the JAXB 2.0 API seems pretty stable, so I guess we can support it. Which poses the following question:

Are there any other features when using JAXB 2 in combination with OXM which you currently miss?

[routis]

Yep, that's a bug. Thanks for creating the JIRA issue, I will fix it soon.

Thanks for the quick reply.

Are there any other features when using JAXB 2 in combination with OXM which you currently miss?

Currently, by avoiding the call to the JaxbMarshaller.setValidation(boolean) the JaxbMarshaller works fine except that JAXB does not validate xml. This is very annoying - at least in my case.
I believe that in JAXB 2 someone has to use the method Unmarshaller.setSchema(schema), in order to validate the xml. I will investigate this.

[routis]

Ok here are the results of my investigation

In JAXB 2 in order to validate an xml against a schema you need something like the following:


// References to the schema files
Source[] schemas = new Source[]{
new StreamSource(schemaFile1),
new StreamSource(schemaFile2)
};

// Obtain schema object
SchemaFactory schemaFactory = schemaFactory.newInstance(XMLConstants.W3C_XML_SCH EMA_NS_URI);
Schema schema = schemaFacotry.newSchema(schemas);

// create unmarshaller
JAXBContext jCtx = JAXBContext.newInstance("foo.bar");
Unmarshaller unmarshaller = jCtx.createUnmarshaller();
unmarshaller.setSchema(shema);


As of version 0.9.1 of spring-oxm the JAXBContext is not exposed via getter/setter methods, but it is constructed internally by JaxbMarshaller. So, in my opinion, currently I the JaxMarshaller cannot validate xml against xml schema.


Please note that I am very new to JAXB and maybe my conclusions are not valid.

[Arjen Poutsma]

Currently, by avoiding the call to the JaxbMarshaller.setValidation(boolean) the JaxbMarshaller works fine except that JAXB does not validate xml. This is very annoying - at least in my case.

As an alternative for validation you could use the PayloadValidatingInterceptor, that is: if you are use the marshaller within a Spring-WS Web service.

I believe that in JAXB 2 someone has to use the method Unmarshaller.setSchema(schema), in order to validate the xml. I will investigate this.

I believe you are correct. We can support this using the same principle as PayloadValidatingInterceptor, i.e. offer a schema property, in which you can inject a schema resource. This wouldn't work under JAXB 1, though, which is kinda ugly.

We could separate the JAXB2 functionality from the JAXB1 stuff by offering a special Jaxb2Marshaller. I don't like this idea too much, though, since the basic functionality (i.e. marshalling) is the same in both the versions. Only the offered properties are different.

I'll think about this.

[routis]

As an alternative for validation you could use the PayloadValidatingInterceptor, that is: if you are use the marshaller within a Spring-WS Web service.

Intresting solution, but it is not correct for me. In my project I do work with xml but not with web services.
I would prefer the autonomy of spring-oxm.

We could separate the JAXB2 functionality from the JAXB1 stuff by offering a special Jaxb2Marshaller. I don't like this idea too much, though, since the basic functionality (i.e. marshalling) is the same in both the versions. Only the offered properties are different.

I just did implement Jaxb2Marshaller and Jaxb1Marshaller that inherit from a common parent that provides the basic functionality. Since Jaxb1 and Jaxb2 are not configured in the same way in my opinion:
1) Either there have to be two distinct classes (Jaxb1Marshaller and Jaxb2Marshaller)
2) Or a single JaxbMarshaller that is not responsible for initializing the JAXB marshaller and unmarshaller. Perhaps a factory could be responsible for that.

[Arjen Poutsma]

I fixed this issue in CVS, and basically took the approach you suggested. The JaxbMarshaller has been refactored into an AbstractJaxbMarshaller, a Jaxb1Marshaller and a Jaxb2Marshaller. Each concrete class allows for different properties to be set (i.e. the Jaxb1Marshaller has a validating property, while the Jaxb2Marshaller has a schema resource).

Could you please checkout the Spring-WS sources and see whether this works for you?

Cheers,

[routis]

Dear poutsma,

Thanks for the fix. Unfortunately, I cannot access the cvs at work (due to restrictive company firewall policy), but I will find a way to see the new code.

By the way I don't understand why the various libraries are in cvs. Since I don't have a broadband internet connection it's very difficult to checkout the project.

Are there any plans for migrating to SVN like spring-rich-client?

[Arjen Poutsma]

Thanks for the fix. Unfortunately, I cannot access the cvs at work (due to restrictive company firewall policy), but I will find a way to see the new code.

By the way I don't understand why the various libraries are in cvs. Since I don't have a broadband internet connection it's very difficult to checkout the project.

The libraries that are in cvs cannot be found on ibiblio, for instance JAXB can only be downloaded from SUN directly. You could look at the code using the Browse CVS functionality of SourceForge here.

Are there any plans for migrating to SVN like spring-rich-client?

Yes, there are plans for SVN. Stay tuned.