Nokogiri::XML::Document#wrap raises undefined method `length' for nil:NilClass when trying to << to a node

[abevoelker]

I'm trying to modify some existing XML that is coming from the iText library, which is in org.w3c.dom.Document form. I'm using the wrap method to load it (very convenient, thank you!). Unfortunately, I am getting an error (verified on JRuby 1.6.8 --1.9 mode and 1.7.0) when trying to modify it. Here is some example code that replicates the issue:

require 'open-uri'
require 'nokogiri'

# apologies for having to load the org.w3c.dom.Document structure as binary
dom = Marshal.load(open('https://gist.github.com/raw/508d3c4b0705b29a10ee/26c9056915373440ed687f6b60d92b13a92715c7/dom'))
doc = Nokogiri::XML::Document.wrap(dom)
doc.xpath("//*[local-name()='field'][@name='text']").each do |node|
  Nokogiri::XML::Builder.with(node) do |xml|
    xml.value_ do
      xml.exData('contentType' => 'text/html') do
        xml.body_('xmlns' => "http://www.w3.org/1999/xhtml", 'xmlns:xfa' => "http://www.xfa.org/schema/xfa-data/1.0/") do
          xml << '<p>foobar</p>'
        end
      end
    end
  end
end

The line that is doing xml << is raising the following error:

NoMethodError: undefined method `length' for nil:NilClass
from /home/abe/.rvm/gems/jruby-1.7.0@noko/gems/nokogiri-1.5.5-java/lib/nokogiri/xml/node.rb:531:in `parse'

I fixed this error by changing the problem line to read

error_count = (document.errors && document.errors.length) || 0

However, the lack of a .gemspec file (which I know you're already well aware of) makes it hard to easily use my hotfixed version from Bundler (e.g. using :git or :path locations). Therefore, my new workaround is to double-load the document, as loading from raw XML (avoiding the wrap method) doesn't trigger the issue:

doc = Nokogiri::XML(Nokogiri::XML::Document.wrap(dom).to_xml)

Apologies for the length of the example code and the use of Marshal.load in showing the issue - if I had more time/knowledge to investigate I would have boiled this down better.

Note: I saw #770, and compiled from master (currently 557e674756) to verify this hasn't been fixed - it still errors.