[SWS-768] Make JAXP13ValidatorFactory smarter Created: 27/Apr/12  Updated: 04/May/12  Resolved: 02/May/12

Status: Closed
Project: Spring Web Services
Component/s: Core, XML
Affects Version/s: 2.0.4
Fix Version/s: 2.0.5

Type: Improvement Priority: Major
Reporter: Gregory bonk Assignee: Arjen Poutsma
Resolution: Deferred Votes: 0
Labels: bean-visibility-and-overriding, webservices, xml, xsd
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Using java 1.5 ( latest sun release ) Spring Core 3.1.1 and Spring-WS 2.0.4


Attachments: Zip Archive planning-ws.zip    

 Description   

We import all of our XSDs through the classpath. The Apache Commons XmlSchema library and springs integration with it has been a real life saver for us. To be able to use our PlanningServiceMessages.xsd to create a dynamic WSDL and have spring handle finding all of our XSDs in their many forms and locations from many groups has been a huge life saver.

I thought it would be a snap then to enable validation for our Requests and responses as well. Just pop our PlanningServiceMessages.xsd into a PayloadValidatingInterceptor and instance validation, but unfortunately I was quickly thwarted by an Xerces error saying that it can't find one of the libraries.

I was really scratching my head as to why I had an error from Xerces, so I started digging. I first looked into the CommonsXsdSchemaCollection since that's what we used also for our WSDL generation. I traced into createValidator and then XmlValidatorFactory which gives me a Jaxp13ValidatorFactory, which is subsequently uses the JDK's built in Xerces SchemaFactory. Unfortunately with Xerces it's pretty brain dead I believe and it doesn't have the powerful schema resolution that we rely on to find the XSDs,

What I did was grab the hidden class ClasspathUriResolver from with-in CommonsXsdSchemaCollection and exposed it as it's own class. I need this because it includes Scoped resolution too for where classpaths start with '..' (SWS-413) Next I implemented a LSResourceResolver within my new ClasspathUriResolver that allowed me to have a new Custom XSDSchema class that would use this resolver to create a validator within Xerces. and finally I implemented a copy of XmlValidator that allowed me to inject my own schema w/o relying on the factory because Jaxp13Validator is hidden as well.

So now I can create a schema that will resolve my XSD classpaths and get a validator from it. I hope this is helpful and inspires people to improve this area.

I did test it with 2.10 of Xerces using the "-Djavax.xml.validation.SchemaFactory" thing and I had the same issue. Xerces would choke on the relative '..' classpaths

Or, you can just tell me how I should have done it in the first place



 Comments   
Comment by Arjen Poutsma [ 02/May/12 ]

The code you attached looks good, but I am not sure how applicable it is to others.

If anyone feels this code should be part of the main Spring-WS distribution, please vote for it, and I will include it in a future release.

Comment by Gregory bonk [ 03/May/12 ]

I expect it to be applicable if people want their validators to setup and operate exactly like their dynamic WSDLs. The existing mechanism for creating a validator is not as user friendly as it is for a dynamic WSDL. W/o my update. I would have to have two sets of XSDs. I'm not clear on why the functionality in CommonsXsdSchemaCollection would not be leveraged to create the schema to create the validator as well.

Comment by Arjen Poutsma [ 04/May/12 ]

Closing old issues

Generated at Sat Dec 16 15:03:45 UTC 2017 using JIRA 6.4.14#64029-sha1:ae256fe0fbb912241490ff1cecfb323ea0905ca5.