-
-
Notifications
You must be signed in to change notification settings - Fork 905
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
Java-Implementation forgets element namespaces #902
Comments
I was able to reproduce this bug with a more simple XML example: <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element xmlns:quer="http://api.geotrust.com/webtrust/query"/>
<xs:element xmlns:quer="http://api.geotrust.com/webtrust/query"/>
</xs:schema> If we iterate over some xpath like |
@andrewhr it seems to be somehow related to iterating over a NodeSet. finding a single element and checking its namespaces works for me: # works
document.root.at_xpath('./xs:element', 'xs' => 'http://www.w3.org/2001/XMLSchema') |
@rubiii I don't think so. In the PR I've sent you I've used the xpath's |
@yokolet would you mind taking a look at this? it's a very annoying problem, but simple to reproduce. |
updated the specs to verify this has nothing to do with xpath. it also happens when traversing. |
this appears to be related to the namespace cache. i don't really get it right now, but somehow cache entries are associated with a single ownerNode? and if the same prefix+href is already registered, it won't be added twice. which is how a cache should work i guess. but since cache entries belong to a single ownerNode, this check fails. |
anything else i can do to get this resolved? |
This may be related to the issue I discovered while tracking down a bug dealing the defautl namespace aliasing, and yes it is in the namespace cache. You can check it out here #940 |
@rdingwell i think i incorporated your fix into a fork of nokogiri, compiled the jar and included it into my test repository via bundler and my tests are still failing. i need to come up with a nokogiri testcase to make this a little easier. maybe you can run these tests to see if your change is realted to this problem. |
I've been able to track this down a little further and there are some real problems with the NokogiriNamespaceCache and the way in which it is used. When parsing a document all of the namespaces are cached but the NokogiriNamespaceCache expects a prefix -> URI mapping to only occur once in a document. So in your example the first element contains the namespace mapping but the second one does not because the NokogiriNamespaceCache already contains that prefix -> URI mapping and it is associated with the first node. The namespace caching in general does not look like it has been very well tested and storing it at the document level seems like a bad idea and storing it in a lazy loading fashion on the node seems like it would be far less error prone and simpler to implement. There wouldn't be a need for attempting to create a hashCode or mapping things to nodes and ensuring correct ownership. I;m not really convinced that what is there now would accurately handle re-defining a prefix to a different uri at a nested level, which is perfectly legal xml. I'll see if there is something that I can put together seeing how I would really like some of the things that I have to run under jruby and currently cannot due to the namespace issue in the java impl of nokogiri. BTW, heres the testcase equiv of your spec file. require "helper"
|
@rdingwell thanks for verifying my assumption! |
Just to keep you updated I issued a pull request that if gets accepted should resolve your issue. #959 |
thanks @rdingwell |
Hi, |
nice! thanks @yokolet |
There is a difference between the latest C and Java version of Nokogiri related to namespaces
defined on child elements with a WSDL file I was testing.
The code to reproduce this problem can be found at rubiii/nokogiri_namespace_issue.
The Travis build shows how the spec only fails on JRuby.
Let me know if you need anything else.
The text was updated successfully, but these errors were encountered: