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

Support parsing without namespace awareness in BeanDefinitionParserDelegate and DefaultBeanDefinitionDocumentReader [SPR-6017] #10686

Closed
spring-projects-issues opened this issue Aug 17, 2009 · 4 comments
Labels
in: core Issues in core modules (aop, beans, core, context, expression) type: enhancement A general enhancement
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

Tuomas Kiviaho opened SPR-6017 and commented

BeanDefinitionParserDelegate and DefaultBeanDefinitionDocumentReader currently use node.getNamespaceURI & getLocalName() without considering that namespace awareness might be turned off (or DOM 1 is in use) leading these methods to return null values. The code is robust enough to avoid NPE:s but all elements belong to default namespace when namespace awareness is off since isDefaultNamespace(String) method will always receive null.

By providing middle-man methods getNamespaceURI(Node) and getLocalName(Node) in delegate as public methods (or alternatively as protected with additional public isDefaultNamespace(Node)) would solve the problem when namespace awareness is turned off (or DOM 1 is used). These methods could be overridden to provide means other means to solve namespace and localname while Spring could by default still stick with DOM 2 implementations.


Affects: 2.5.6

Referenced from: commits 320f08a, 7835e66, 7d37c92, 019c3c2

@spring-projects-issues
Copy link
Collaborator Author

Rob Harrop commented

Tuomas,

I committed the changes you requested but I'm not sure they will be sufficient. The namespace handlers themselves make use of getLocalName(). Does your use case require this?

Thanks,

Rob

@spring-projects-issues
Copy link
Collaborator Author

Tuomas Kiviaho commented

I reviewed the changes and they seem to be exactly what I intended. I have forgotten to check NamespaceHandlerSupport and indeed it has DOM1 issues as well (node.getLocalName). I noticed that there is a nodeNameEquals already but taking care of NamespaceHandlerSupport with getLocalName middle-man method similar to getNamespaceURI would really make my day. I see that parser context and therefore delegate isn't distributed to all of the protected methods using getLocalName so the change wouldn't be backwards compatible,

Anyway from my perspective I consider this issue to be fixed as-is. Thanks a lot.

@spring-projects-issues
Copy link
Collaborator Author

Rob Harrop commented

Tuomas,

Thanks for your comments, I'm glad the changes work for you.

I'll discuss with Juergen about maybe extending this out to NamespaceHandlerSupport as well, but that may well happen post-3.0 now.

Thanks,

Rob

@spring-projects-issues
Copy link
Collaborator Author

Rob Harrop commented

Tuomas,

I did a bit more work on this and now all namespace handler code is using the delegate for local name lookup so you changes you make there will be a lot more effective.

Regards,

Rob

@spring-projects-issues spring-projects-issues added type: enhancement A general enhancement in: core Issues in core modules (aop, beans, core, context, expression) labels Jan 11, 2019
@spring-projects-issues spring-projects-issues added this to the 3.0 RC1 milestone Jan 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core Issues in core modules (aop, beans, core, context, expression) type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

1 participant