Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make JAXP13ValidatorFactory smarter [SWS-768] #853

Closed
gregturn opened this issue Apr 27, 2012 · 3 comments
Closed

Make JAXP13ValidatorFactory smarter [SWS-768] #853

gregturn opened this issue Apr 27, 2012 · 3 comments

Comments

@gregturn
Copy link
Contributor

gregturn commented Apr 27, 2012

Gregory bonk opened SWS-768 and commented

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 '..' (#509) 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 :-)


Affects: 2.0.4

Attachments:

@gregturn
Copy link
Contributor Author

gregturn commented May 2, 2012

Arjen Poutsma commented

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.

@gregturn
Copy link
Contributor Author

gregturn commented May 3, 2012

Gregory bonk commented

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.

@gregturn
Copy link
Contributor Author

gregturn commented May 4, 2012

Arjen Poutsma commented

Closing old issues

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants