Nokogiri's xpath function is quite aware of namespaces. In fact, nokogiri's xpath function is a thin wrapper around libxml2, so I'm curious why you think it treats namespaces as "clever attributes"?

Your sample document does not declare your rdf tags inside a namespace. Please try a sample RDF document that declares the tags using namespaces. Here is a good example:

http://www.w3schools.com/rdf/rdf_example.asp

Notice how the sample rdf document provided by w3schools declares it's namespaces, where your document does not.

Also, xml documents may only have one root node. If there are multiple nodes, it is not a legal XML document:

http://www.w3.org/TR/REC-xml/#dt-root

According to the RDF/XML spec, it may have multiple rdf:RDF, but they must be inside a root tag:

http://www.w3.org/TR/rdf-syntax-grammar/#section-grammar-summary

Also see section 7.2.8

Actually, my bad. The XPath tests I had written were wrong, but also the XML I had pasted into the orginal message had got the formatting screwed up.

Sorry to waste your time.

I'm not sure what to do about this. It's working for me:

http://skitch.com/aaron.patterson/b9ecb/terminal-bash-80x24

I can't repro this and the ticket hasn't been updated for almost a month. I will assume this is fixed on master.

Please reopen and update the ticket if it's still breaking against master. Thanks.

Francois,

Thanks for using Nokogiri!

Nokogiri is not supported under JRuby 1.2. You can take a look at issue #8 for the current status on JRuby support.

We are targetting JRuby 1.3 for an alpha release of Nokogiri-FFI. Currently all tests pass on 1.3.0RC1, which was just released today.

-mike

Ya, thought of this last night. I'll have a fix soon.

adding initialize to all nodes. closed by 9f904ba
Squashed commit of the following:

commit 14514e7
Author: Aaron Patterson aaron.patterson@gmail.com
Date: Sat May 16 19:18:40 2009 -0700

fixing up attribute initialize

commit 2969620
Author: Aaron Patterson aaron.patterson@gmail.com
Date: Sat May 16 19:16:45 2009 -0700

fixing xml comment initialize

commit ed4affc
Author: Aaron Patterson aaron.patterson@gmail.com
Date: Sat May 16 19:13:12 2009 -0700

fixing entity reference initialize

commit 87706dd
Author: Aaron Patterson aaron.patterson@gmail.com
Date: Sat May 16 19:11:07 2009 -0700

adding initialize for processing instruction

commit e02d099
Author: Aaron Patterson aaron.patterson@gmail.com">aaron.patterson@gmail.com
Date: Sat May 16 19:05:42 2009 -0700

getting document fragment working

commit eed074e
Author: Aaron Patterson aaron.patterson@gmail.com
Date: Sat May 16 19:02:03 2009 -0700

fixing text node initialize

commit 84cfbed
Author: Aaron Patterson aaron.patterson@gmail.com
Date: Sat May 16 19:00:28 2009 -0700

starting work on initialize method

I wrote a patch for this. It uses #start_element_ns and #end_element_ns. It maintains backward compatibility with #start_element and #end_element.

http://github.com/sprsquish/nokogiri/commit/775c298b49b0b085b024aa098aaf412b90269d4a

I'm mostly OK with this patch. It shouldn't use rb_str_new2 as that will produce strings of the incorrect encoding in 1.9.

I'll apply it and fix it up.

If you haven't already, I can clean it up and re-submit. Those rb_str_new2 calls were oversites on my part.

If you don't mind, that would be great! If you clean up the rb_str_new2 calls, I'll apply it.

Okay, I removed the direct calls to rb_str_new*, fixed the little space mistake in xml.rb and gave proper credit to the libxml guys.

I force updated the remote branch figuring no one else was paying any attention to my fork.

http://github.com/sprsquish/nokogiri/commit/660362805ff06cd36465d08bf6dda67af6867c4f

applied. thanks!

Specifically the error that I get is:

checking for xmlParseDoc() in -lxml2... no
libxml2 is missing.  try 'port install libxml2' or 'yum install libxml2'

yes, but you need the libxml2 development packages installed.

do this: "aptitude install libxml2-dev"

You may need to do a similar thing for libxslt

Yup, I do have libxml2-dev installed:

root@shire:~# apt-get install libxml2-dev libxslt-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
libxml2-dev is already the newest version.
Note, selecting libxslt1-dev instead of libxslt-dev
libxslt1-dev is already the newest version.

And yet above error while installing nokogiri 1.2.3

You wouldn't happen to have libxml-dev installed, would you?

Well lets see:

root@shire:~# apt-get remove --purge libxml-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package libxml-dev is not installed, so not removed

alright. Run 'gem env' then go to the "INSTALLATION DIRECTORY". There should be a file "gems/nokogiri-1.2.3/ext/nokogiri/mkmf.log". Get that file and put it on gist or something. That will give me more insights in to your system config, and should tell us what the problem is.

Here is the gist: http://gist.github.com/100625

Do you have ruby-dev installed as well?

I have ruby compiled from source and as shared library and hence that could be the reason behind "unable to find ruby-static" errors.

In related note:

5070 lib % nm libxml2.a|grep xmlParseDoc                                                                                   hemant pts/7
00017200 T xmlParseDoc
000092b0 T xmlParseDocTypeDecl
00016560 T xmlParseDocument
         U xmlParseDocument
         U xmlParseDoc
         U xmlParseDocument
         U xmlParseDocument
         U xmlParseDocument
/usr/lib

However, I have shared library version of libxml2 as well ( but nm command won't work on shared libraries AFAIK). This is getting nasty no doubt, I will see if I can configure nokogiri with custom compiled libxml2.

Okay. I'm going to close this because it sounds like environment issues

I'd also like to add that if you have a document like this:

<element>
  <c1 xmlns="one" />
  <c2 xmlns="two" />
</element>

then

doc.root.collect_namespaces.inspect #=> {'xmlns' => 'two'}

Yup. That is the danger of collect_namespaces. I think that method should be removed.

The first problem is fixed here: c6e5fa0

raising an exception if someone tries to reparent a *::Document. closed by c557764

What version of libxml2 are you using? Past the contents of this command, if you can:

$ nokogiri -v

Also, if you could post the code to reproduce this, that would be great. So far, libxml2 is behaving how you want it to:

d = Nokogiri::XML('<root />')
d.root['foo'] = 'hello " world'

puts d.to_xml # => '<root foo="hello &quot; world"/>'

Closing as there has been no response.

I've applied the patch, but next time please make sure the tests pass. After applying the patch, I got these errors:

  1) Error:
test_raw_append(Nokogiri::XML::TestBuilder):
NoMethodError: undefined method `content' for nil:NilClass
    test/xml/test_builder.rb:127:in `test_raw_append'

  2) Error:
test_raw_append_with_instance_eval(Nokogiri::XML::TestBuilder):
NoMethodError: undefined method `content' for nil:NilClass
    test/xml/test_builder.rb:137:in `test_raw_append_with_instance_eval'

XML Builder can append raw strings. closed by 98b10d2

Yeah, I pasted the wrong patch. Sorry about that.

No problem! :-)

This was fixed here: e4976fd

and is a dup of #160

This might be related to lighthouse ticket 53 but that ticket was resolved before the patch was made. Specific comment is:

We need to do the same thing for add_previous_sibling, and add_next_sibling I suspect.

Nope, I think this is a different problem. I'll take a look

doing a type check on methods that modify the tree. closed by 762c832 closed by 762c832

I think this is the same issue as #29. I'm going to raise an ArgumentError exception in those methods if you're not passing in a Node.

Oops. This got fixed with 762c832

jmhodges - what version of Nokogiri are you using?

With 1.2.3 I cannot reproduce. On 1.2.4 I get an encoding error:

encoding error : output conversion failed due to conv error, bytes 0xE7 0xB7 0x10 0x3D
I/O error : encoder error

Yeah, 1.2.4 and 1.2.3 for me. Here's a gist of an irb session that didn't segfault immediately with nokogiri 1.2.3 and here's one that did with nokogiri 1.2.4.

As you can see, I only get the error you did when the code does not segfault in 1.2.3. What is the output of meta_tag.to_s (l.to_s in those posts) on your machine?

I did see similar errors in a larger file that had some entities seemingly translated to utf-8 while the file was being parsed (I believe! Not sure!) as ISO-8859-1.

Sorry, added a simpler bit of code that expresses it. Using #at instead of #traverse.

whoop, I've managed to get valgrind to complain. consider it reproduced, and I'm on the case.

Cool, I wasn't able to get the OS X beta valgrind to talk to me much about it but I haven't used it before. If you want, I can run it again and post something up (assuming, you're not already on OS X).

This is a libxml2 bug. I just wrote a C program that reproduces it, and will be submitting it to libxml2's tracker tonight.

C program to reproduce is at http://gist.github.com/112897

Bug has been filed at http://bugzilla.gnome.org/show_bug.cgi?id=582913

mdalessio, I love you a little bit. Never change. <3

Also, sorry for not hunting this down myself. I got lost in a thicket of build problems last night.

awwww, now you made me blush.

closing this ticket, since it's now in the good hands of the libxml2 team.

F yer I: Daniel V (maintainer of libxml2) has updated the libxml2 bugzilla ticket. Here's his comment

Okay, I have fixed htmlSetMetaEncoding() to be nicer,
not destroy existing meta encoding elements just update the
property and only if needed, which is never the case if you
just output part of the current document without asking for encoding
changes.
Fixed in git (<a href="/tenderlove/nokogiri/commit/8d7c1b7ab296ea2e8c8d18d7b8f3d24e0963f8ff">8d7c1b7</a>)

 thanks for the report,

Daniel

You might want to check out that version and verify that it addresses your particular pain. Have a nice day.

I concur that this appears to be a memory leak. I would like to point out, though, that when running the same code on ruby-ffi (MRI), there is no leak.

This leads me to quietly, gently, and without proof, suggest that perhaps this is a JRuby/FFI problem.

I will put together some tests to try to reproduce these results in a vanilla (non-Nokogiri) case, and perhaps narrow the search for causes.

I have created a self-contained self case demonstrating the problem, which is available at http://gist.github.com/156081

I've opened a JIRA ticket for the JRuby team: http://jira.codehaus.org/browse/JRUBY-3832

I'll leave this ticket open for a few days, and will provide updates when I hear from the JRuby team.

I believe it's a ffi/jruby problem too.
I get the same kind of problem if replace

doc = Nokogiri::HTML(xml)

with

doc=Nokogiri::LibXML.xmlReadMemory(xml, xml.length, nil,nil, nil)

which goes straight to the "attached" libXML function.

See an update from Wayne (JFFI team) here:

http://jira.codehaus.org/browse/JRUBY-3832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=185050#action_185050

This fix is available now if you want to build JFFI yourself, or else you can wait until JRuby 1.3.2 (or 1.4.0). Details at the above URL.

Closing this ticket.

Just an FYI, the latest JFFI does not appear to fix this issue. I've updated the JFFI ticket.

Another update: current JFFI addresses this issue. Though it is still possible, with aggressive-enough memory usage, to get an OOM memory condition, it is vanishingly likely that using Nokogiri will cause a full-blown OOM.

The original test code no longer suffers from the monstrous memory leak. I'm considering this issue 'closed', for realsies. Let me know if you're still experiencing issues after upgrading to the latest JFFI.

Right, because it returns a Nokogiri::XML::Text node. That is different than a string.

delegating DocumentFragment#css to the fragment children. closed by ed10f01

Should have noted that this occurs both on Mac OS X (libxml2 2.7.3) and Gentoo Linux (libxml2 2.7.2).

This is more of the node dictionary allocation issue, which occurs when nodes have resources owned by another document. In this case, when the node is dup()ed, it still references dictionary strings owned by the original document. At GC time, things blow up.

Basically, libxml2 does not support moving nodes from one document to another, nor does it support moving dupes of a node to another document. Sigh.

But this shouldn't be that problem, right? I thought we copied the tree on dups?

This is that problem! Really. I think if we copy the document, everything works correctly. But copying a node and jamming it into another doc is definitely going to break libxml.

moving roots around will copy them and gc old roots. closed by 10f5710

This also applies to other HTML -- I have observed it with anchors, i.e., "One line\nTwo line\n\n<a href="http://brokenlink.com">This won't be a link after parsing</a>"

However, if I wrap the text block in a <div> and </div>, it works. I'm thinking that the newline must somehow interfere with Nokogiri's ability to discern the insides as HTML.

OK, will investigate.

fixing leading text node with newline in fragment parsing. closed by b659302.

Great turnaround time, thanks a lot! Between this and the fix to the document.root.namespace exception you recently did, I'd love to see a gem bump soon so I can strip out my collection of kluge-fixes. :)

Should be bumped this weekend. Cross your fingers.

What version of libxml2?

Looks like 2.7.3.

If you were on libxml2, 2.6.16, then I wouldn't be surprised. That version was very old an unstable.

I can't repro this (even with thousands of iterations), so I will assume it's a bug with 2.6.16. I am going to close this, but if you are able to repro with 2.7.3, please reopen this ticket. Thanks!

Shouldn't require thousands of iterations, it's a happens-every-time kind of bug. However, I may have been wrong about the version of nokogiri I was using. It might have been edge.

Node#matches? works in nodes contained by a DocumentFragment. closed by d41db1a

Yo. This is fixed in master. Commit 1fefd59

Strange. Are you sure nokogiri -v returns the same thing on the linux box? That seems crazy.

Yeah - I thought I was going crazy so I even did a diff. Weirdest thing I've seen... AFAIK libxml2 doesn't really depend on much does it? Or is there something else that Nokogiri depends on that might be causing this? I tried libxml2 2.7.2 just in case, but still had the same problem.

libxml2 only depends on iconv and zlib. Neither of those should cause this problem.

What linux are you running?

Gentoo (default/linux/x86/2008.0 profile) over the 2.6.18-xenU-ec2-v1.0 kernel

libxml2: 2.7.3-r2
libc: 2.8_p20080602-r1
zlib: 1.2.3-r1

Okay. I'll get a gentoo box up and running. Might be a little while before I get this one to repro. :-(

Thanks a ton! In the meantime I'm trying to upgrade glibc and anything else that might be out of date, just to try some different versions of things.

FWIW - The new glibc (2.9_p20081201-r2) didn't affect anything.

Here's another take on it, if it helps at all:

require 'test/unit'
require 'rubygems'
require 'nokogiri'

module Nokogiri::XML
  class Node
    include Test::Unit::Assertions

    def inner_html=(tags)
      children.each { |x| x.remove }

      assert_equal ['sup', 'sub'], document.fragment(tags).children.map {|n| n.name }
      document.fragment(tags).children.to_a.each do |node|
        add_child node
      end
      self
    end
  end
end

class BugTest < Test::Unit::TestCase
    def test_should_parse_inner_html
        text = '<base><one>1</one><two>2</two></base>'

        doc = Nokogiri::XML(text)
        base_tag = doc.at('base')
        base_tag.inner_html = "<sup>#{base_tag.at('one').inner_text}</sup><sub>#{base_tag.at('two').inner_text}</sub>"

        assert_equal ['sup', 'sub'], base_tag.children.map {|n| n.name }
    end
end

Successful return on the MacPorts install, and on the Linux install:

  1) Failure:
test_should_parse_inner_html(BugTest)
    [oo2.rb:12:in `inner_html='
     oo2.rb:27:in `test_should_parse_inner_html']:
<["sup", "sub"]> expected but was
<["sup"]>.

In fact, even just this code returns only the first element and not the other:

Nokogiri::XML::DocumentFragment.parse("<one>1</one><two>2</two>")

Unless it's wrapped in another outer element like:

<x><one>1</one><two>2</two></x>

...then it returns the whole thing. And then obviously on the MacPorts install it returns an accurate copy regardless of the surrounding element.

I think I narrowed this down finally. For whatever reason, my local copy of Nokogiri (even though the gem was labeled 1.3.3) showed this diff from the copy on the linux machine (which was recently installed):

8,9c8,13
<         @html_eh        = node.kind_of? Nokogiri::HTML::DocumentFragment
< 
---
>         @klass          = if node.kind_of?(Nokogiri::HTML::DocumentFragment)
>                             Nokogiri::HTML::DocumentFragment
>                           else
>                             Nokogiri::XML::DocumentFragment
>                           end
>         #
23,25c27,28
<         regex = @html_eh ? %r{^\s*<#{Regexp.escape(name)}}i :
<                            %r{^\s*<#{Regexp.escape(name)}}
< 
---
>         regex = (@klass == Nokogiri::HTML::DocumentFragment) ? %r{^\s*<#{Regexp.escape(name)}}i \
>                                                              : %r{^\s*<#{Regexp.escape(name)}}

So a fresh install on my MacPorts version now fails as well - lol - not quite the expected result. However, installing the gem from the master works great - so looks like this was already fixed ;)

Ugh. You're right. It fails against 1.3.3. I was checking against master. :-(

I guess I can stop fighting with VirtualBox now. Thanks for letting me know!

bump anybody?

Working on it.

making sure HTML fragments include comments and cdata blocks. closed by 8019e01.

What version of libxml2 are you using? It seems to be serializing OK (no strange CDATA stuff) for me, and I'm on 2.7.3

I have no idea which version. How do I find out?

If you're running nokogiri 1.3.x, just do this:

$ nokogiri -v

Otherwise, in irb, require nokogiri, then print out Nokogiri::LIBXML_VERSION

2.6.30 locally (OSX), 2.6.26 (CentOS 5.1) on staging.

I can't seem to reproduce this at all. Would you mind writing a failing test case? I've tried the following test case using libxml2 version 2.7.3, 2.6.30, and 2.6.26. All of them pass. I'm afraid I'm not writing the test correctly.

require 'nokogiri'
require 'test/unit'
require 'open-uri'

HTML = open('http://online.wsj.com/article/SB124514075458818255.html').read

class TestCDATA < Test::Unit::TestCase
  def test_cdata
    before = HTML.scan(/CDATA/).length
    doc = Nokogiri::HTML HTML
    assert_equal before, doc.to_s.scan(/CDATA/).length
  end
end

This fails for me:

require 'nokogiri'
require 'test/unit'
require 'open-uri'

HTML = open('http://online.wsj.com/article/SB124514075458818255.html').read

class TestCDATA < Test::Unit::TestCase
  def test_cdata
    before = HTML.scan(/\[/).length
    doc = Nokogiri::HTML HTML
    assert_equal before, doc.serialize.scan(/\[/).length
  end
end

Okay. This is definitely a problem in libxml2. 2.6.26, 2.6.30, and 2.6.32 all fail. The good news is that libxml2 2.7.3 passes the test.

Updating macports to 2.7.3 is easy (just port install libxml2 and libxslt). I'm not sure about CentOS though. I'm going to close this since it's a bug in libxml2.

Test case: http://gist.github.com/149234

you need to properly use namespaces. Nokogiri supports standard XPath, and Hpricot does not.

puts "[Nokogiri] size = #{xml.xpath('//xmlns:Video').size}" # => 10

the above gives you the right answer of 10.

you can read more about this on tenderlove's blog, at http://tenderlovemaking.com/2009/04/23/namespaces-in-xml/

Totally fixed this thing

4fcb719

Done

Added relaxng and xml schema support 469d528

fixed in 507c953

Added tag lookup code

e9e6a65

Watch me pull this rabbit out of my hat ...

ruby-ffi (MRI) now passes all tests except 4, which involve how whitespace is being escaped.

jruby FFI is another story. hit another blocker last night where a regression was introduced. will open a JRUBY ticket on kenai once I have a failing spec.

opened http://jira.codehaus.org/browse/JRUBY-3584, which was a regression

FFI branch now has only 15 errors against jruby master.

FFI branch has been merged into master. Waiting for jruby 1.3 to be released.

All tests pass on jruby 1.3.0RC1.

Closing! Nokogiri 1.3.0 will contain this code. Currently our RC (which looks like 1.2.4) is totally green on JRuby 1.3.0 and later.

Woot! Internet High Five

It is not work with jruby 1.3.1.
I have following error:
jirb
irb(main):001:0> require 'rubygems'
=> true irb(main):002:0> require 'nokogiri'
LoadError: Could not open any of [xml2, xslt, exslt]

from /home/dan/installed/jruby/lib/ruby/1.8/ffi/library.rb:18:in `ffi_lib'
from /home/dan/installed/jruby-1.3.1-rails/lib/ruby/gems/1.8/gems/nokogiri-1.3.3-java/lib/nokogiri/ffi/libxml.rb:5
from /home/dan/installed/jruby-1.3.1-rails/lib/ruby/gems/1.8/gems/nokogiri-1.3.3-java/lib/nokogiri/ffi/libxml.rb:31:in `require'
from /home/dan/installed/jruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require'
from /home/dan/installed/jruby-1.3.1-rails/lib/ruby/gems/1.8/gems/nokogiri-1.3.3-java/lib/nokogiri.rb:10
from /home/dan/installed/jruby-1.3.1-rails/lib/ruby/gems/1.8/gems/nokogiri-1.3.3-java/lib/nokogiri.rb:36:in `require'
from /home/dan/installed/jruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `require'
from (irb):3

This issue is closed. Please open a new one.

Also, please make sure you actually have libxml2 and libxslt installed on your machine.

I create issue here:
http://github.com/tenderlove/nokogiri/issues/#issue/120

But the format looks terrible.

Fixed here: df9a6f2

fixed in d5b5a08

fixed here. c1459a3

Nope, I was stupid and thought this was still set to open. My bad.

The reader API actually was fine. It just needed more documentation. closed by 1153cc3

adding NodeBuilder#[] and NodeBuilder#[]= closed by 9dd0a39

adding lots of documentation. closed by 10d8617

gah, I suck. It does match the xml interface because it inherits from the xml interface. ugh.

adding an rdoc test and adding lots of rdoc. closed by acddc4a

adding documentation for Nokogiri::XML::SAX::Parser closed by 6a45aef

making the parser return normalized strings. closed by 21c3478

implemented NodeSet#& (intersection). closed by f63a739.

converted NodeSet#+ to C. closed by be5fbf8.

xmlXPathHasSameNodes returns true if any node is present in both. it should be named xmlXPathHasAnyNodeInCommon.

What a terrible name for a function!

implementing a bunch of NodeSet elements. closed by 8188b10

implement NodeSet#include? using libxml function (instead of relying on Enumerable). closed by 5229c4f.

Ooh, I like. +1.

Block configuration for parsing HTML and XML. Closed by c73ac78
Squashed commit of the following:

commit a428cae
Author: Aaron Patterson aaron.patterson@gmail.com
Date: Tue May 19 14:27:33 2009 -0700

parse now takes a configuration block

commit 1780cc7
Author: Aaron Patterson aaron.patterson@gmail.com
Date: Tue May 19 14:16:53 2009 -0700

parse takes block for options

commit ef1a2a7
Author: Aaron Patterson aaron.patterson@gmail.com
Date: Tue May 19 14:01:06 2009 -0700

moving constants around

unfortunately my dream syntax will not work for the same reason that you must register urls in xpath queries. ugh. So I added a couple methods for looking up nodes with a fully qualified ns.

adding a couple methods for finding attributes with namespaces. closed by e46e1a9

nodes may be subclassed. closed by 182394d

Fixed with e7a4588

The current sax parser completely ignores attribute namespace hrefs.

Fixed with 507b912

Blech.

Nokogiri.parse will assume HTML if parameter is an IO object. closed by 42d3548

adding an xml declaration SAX callback handler. closed by b1d7523

I forgot, people seem to get this error:

C:/Program Files/JRuby/jruby-1.3.1/bin/../lib/ruby/1.8/ffi/ffi.rb:
114:in `create
_invoker': Function 'calloc' not found in [exslt] (FFI::NotFoundError)
       from C:/Program Files/JRuby/jruby-1.3.1/bin/../lib/ruby/1.8/
ffi/library.
rb:50:in `attach_function'
       from C:/Program Files/JRuby/jruby-1.3.1/bin/../lib/ruby/1.8/
ffi/library.
rb:48:in `each'
       from C:/Program Files/JRuby/jruby-1.3.1/bin/../lib/ruby/1.8/
ffi/library.
rb:48:in `attach_function'
       from C:/Program Files/JRuby/jruby-1.3.1/lib/ruby/gems/1.8/gems/
nokogiri-
1.3.2-x86-mswin32/lib/nokogiri/ffi/libxml.rb:54
       from C:/Program Files/JRuby/jruby-1.3.1/lib/ruby/gems/1.8/gems/
nokogiri-
1.3.2-x86-mswin32/lib/nokogiri/ffi/libxml.rb:31:in `require'
       from C:/Program Files/JRuby/jruby-1.3.1/bin/../lib/ruby/
site_ruby/1.8/ru
bygems/custom_require.rb:31:in `require'
       from C:/Program Files/JRuby/jruby-1.3.1/lib/ruby/gems/1.8/gems/
nokogiri-
1.3.2-x86-mswin32/lib/nokogiri.rb:10
       from C:/Program Files/JRuby/jruby-1.3.1/lib/ruby/gems/1.8/gems/
nokogiri-
1.3.2-x86-mswin32/lib/nokogiri.rb:36:in `require'
       from C:/Program Files/JRuby/jruby-1.3.1/bin/../lib/ruby/
site_ruby/1.8/ru
bygems/custom_require.rb:36:in `require'
       from TestNokogiri.rb:3

This was fixed here: 70ad006

using host OS to figure out ENV["PATH"]. closed by 544b431

meta_encoding and meta_encoding= are implemented in ruby. closed by ceffd26

updating changelog. closed by 1f658f0

adding DTD external id an system id. closed by 303b2b2

+1

You're supposed to use the upvote button! ;-)

Although, I like the +1 better because it's not anonymous.

This was removed in c7eb4b2

Fixed in 55fbf25

Commit bfa172d allows to set the RECOVER option for PushParser. This resolves the issue.

Ok, cool. I'll close this ticket then.

adding the filter method on node set. closed by 90d4de3

This was fixed in 8111e7b

I've pushed a branch named 'soap4r-bug' that reproduces this problem in the Nokogiri test suite.

adding tests for soap4r adapter and bugfixes. closed by ecdcb0a

This was fixed.