Interesting
String#to_xs behavior can change if you happen to have the fast_xs gem installed.
Rails tries to require the 'fast_xs' c-extension to implement String#to_xs (it falls back to a pure Ruby XML escaping algorithm if it can't find it). Unfortunately, fast_xs is not API compatible with the built-in version provided by Rails (it escapes double quotes, for no apparent reason).
This is all well and good if that's what you decide go with. But unfortunately, fast_xs is a c-extension, which means that if it's been installed on your system for whatever reason (say, installing Hpricot), then Rails will start using it, and there's no good way to turn it off (unless you consider hacking your ActiveSupport gem "good"). So the behavior of your app could change without any explicit intention on your part.
fast_xs also exists as a gem that wraps the c-extension, and if you use to_xs (i.e. your app emits XML), it might behoove you to depend on the gem explicitly. It was noted that for apps that emit a lot of XML to be performant, you will need fast_xs, anyway.
Interestingly, it turns out that JRuby has yet a third implementation of #fast_xs which will escape the XML differently than both the ActiveSupport ruby implementation of #to_xs and the fast_xs C extension.
In summary: #to_xs (ActiveSupport): escapes <, >, and & #fast_xs (C): escapes <, >, &, and " #fast_xs (JRuby): escapes <, >, &, ", and ' (and possibly others)
As with the C version, if you're using JRuby you get the JRuby version whether you like it or not.
Grrr, markdown.
To be clear, the Java implementation of #fast_xs comes from Hpricot, not from JRuby itself. Installing the Hpricot gem using JRuby brings in the hpricot-java library, which has the not-consistent-with-anything-else implementation of #fast_xs.
Coworker and I just spent 3 hours trying to figure out why is our Rails loading activating the Hpricot 0.8.1 gem without us specifying it.
We pinpointed fast_xs by augmenting
Gem.activatemethod to raise an error whenever it tries to activate the 'hpricot' gem. This left me wondering is there a more graceful method to debugging such load issues.@mislav - I first try using RubyGems reverse dependency command:
That will tell you what depends on hpricot. Sometimes this is difficult, though, especially if there is a long dependency chain.