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

AbstractStaxXMLReader should recognize standard features such as the string interning feature [SPR-14047] #18619

Closed
spring-issuemaster opened this issue Mar 12, 2016 · 4 comments
Assignees
Milestone

Comments

@spring-issuemaster
Copy link
Collaborator

@spring-issuemaster spring-issuemaster commented Mar 12, 2016

Philippe Marschall opened SPR-14047 and commented

We use the validation support in Spring WS to validate SOAP requests. Profiling has shown that we have a lot of caught SAXNotRecognizedException during normal program execution. They come from AbstractXMLReader#getFeature which is called from [ValidatorHandlerImpl#validate](http://grepcode.com/file/repo1.maven.org/maven2/xerces/xercesImpl/2.11.0/org/apache/xerces/jaxp/validation/ValidatorHandlerImpl.java#730). ValidatorHandlerImpl checks for the value of the string interning feature. Throwing a SAXNotRecognizedException is interpreted the same way as returning false.

Recognizing the feature and returning false preserves the semantics but gets rid of the SAXNotRecognizedException during normal control flow.


Affects: 4.2.5

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Mar 12, 2016

Philippe Marschall commented

pull request
#1003

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Mar 14, 2016

Juergen Hoeller commented

I've implemented this a bit differently: AbstractXMLReader.getFeature returns false for any feature within {http://xml.org/sax/features/} now, and setFeature accepts false values for any such feature, throwing SAXNotSupportedException otherwise.

Strictly speaking, we even need to do this for some of the features within that namespace at least, since the XMLReader javadoc mandates it for all implementations. It seems sensible to behave that way for all standard feature names then.

Juergen

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Mar 14, 2016

Philippe Marschall commented

That's even better. Should I simply close the PR?

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Mar 14, 2016

Juergen Hoeller commented

Yes please. I'm going to push the wider fix in just a bit.

Juergen

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.