You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 :-)
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.
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:
The text was updated successfully, but these errors were encountered: