Come si fa a trattare con il conflitto tra ActiveSupport :: JSON e JSON la gemma?

Question

Stumped con questo problema.

ActiveSupport::JSON definisce to_json su vari oggetti core e così fa la gemma JSON. Tuttavia, l'implementazione non è la stessa - la versione ActiveSupport prende argomenti e la versione JSON gioiello non si

.

ho installato una gemma che ha richiesto la gemma JSON e la mia app rotto. Il problema è che sto usando to_json in un controllore che restituisce un elenco di oggetti, ma voglio controllare quali attributi vengono restituiti.

Quando il codice ovunque nel mio sistema non require 'json' ottengo questo messaggio di errore:

TypeError: wrong argument type Hash (expected Data)

Ho provato un paio di cose che ho letto on-line per risolvere il problema, ma niente ha funzionato. Ho finito per ri-scrivere il gioiello da utilizzare al posto di ActiveSupport::JSON.decode JSON.parse.

Questo funziona ma non è sostenibile ... Non posso essere che si biforcano gemme ogni volta che voglio usare una gemma che richiede la gemma JSON.

Aggiornamento:. La migliore soluzione di questo problema è quello di effettuare l'aggiornamento a Rails 2.3 o superiore, che ha fissato lo

Answer 1

Update This fix is only applicable to Rails < 2.3. As Giles mentions below, they fixed this in 2.3 internally using much the same technique. But beware the json gem's earlier attempt at Rails compatibility (json/add/rails), which, if required explicitly will break everything all over again.

Do you mean the require 'json' statement itself raises that Exception? Or do you mean when you call @something.to_json(:something => value) you get the error? The latter is what I would expect, if you have a problem requiring the JSON gem then I'm not sure what's going on.

I just ran into this problem with the oauth gem. In my case, there is not a true conflict, because the oauth gem doesn't depend on to_json implementation. Therefore the problem is that JSON is clobbering the ActiveSupport declarations. I solved this by simply requiring json before ActiveSupport is loaded. Putting

require 'json'

inside the Rails::Initializer did the trick (though putting it after the block did NOT).

That allows ActiveSupport to clobber the default JSON implementation instead.

Now if you are using a gem that actually depends on the JSON implementation of to_json then you are up a creek. This is definitely the worst of meta-programming, and I would advocate for the Rails and JSON gem developers to resolve the conflict, though it will be painful because one or the other will have to break backwards compatibility.

In the short term, gem authors may be able to bridge the gap by supporting both implementations. This is more or less feasible depending on how the gem uses the method. A worst case scenario is an official fork (ie. gem and gem-rails).

Answer 2

UPDATE: Even with Rails 3.2, the same problem remains unfixed. The nasty hack to forcibly load the json gem and overwrite it, that is.

Eventually I ended up with the following code, to entirely bypass ActiveSupport's to_json completely. Put it in config/initializers/patches.rb, and you can do {}.jsonize or [].jsonize to generate JSON string. No conflicts with anything, guaranteed.

# Undo the effect of 'active_support/core_ext/object/to_json'
require 'json'
[Object, Array, Hash].each do |klass|
  klass.class_eval <<-RUBY, __FILE__, __LINE__
    def jsonize(options = nil)
      ::JSON.generate self, :quirks_mode => true
    end
  RUBY
end

The 8 lines of code make your app 50 times faster for JSON encoding. Probably you want to do the same. :)

---

I've been having a similar problem up until Rails 2.3.8.

The problem is that ActiveSupport::JSON.backend = 'JSONGem' is a half-assed solution and you still need to overwrite some encoders yourself. (WARNING: for Rails 3.x, which uses MultiJson, it must be ActiveSupport::JSON.backend = :json_gem at least, or it will be silently no-op.)

In my case, I needed to overwrite String#to_json because JSON gem 1.4.3 is better in that it doesn't blindly encode non-ascii-but-valid-UTF8 characters in the form of "\uXXXX" where it's not necessary, so you get shorter bytes (good for serialization) and easy-to-read results ("日本語" looks much sexier to my eyes than "\u65e5\u672c\u8a9e").

Here's the monkey patch that I've been using - put the following code in config/initializers/patches.rb

module ActiveSupport
  module JSON
    module Encoding
      class << self
        def escape(string)
          ::JSON.generate([string])[1..-2]
        end
      end
    end
  end
end

and you're free to use to_json on anything - String, Array and Hash.

Answer 3

After battling this for a while.. I found the simplest solution to be:

if defined?(ActiveSupport::JSON)
  [Object, Array, FalseClass, Float, Hash, Integer, NilClass, String, TrueClass].each do |klass|
   klass.class_eval do
    def to_json(*args)
      super(args)
    end
    def as_json(*args)
      super(args)
    end
   end
  end
end

put that anywhere after activesupport is loaded..

Answer 4

I'm pretty sure they fixed this in 2.3 but I can't remember how.

Answer 5

In my albeit unique case, I had a Ruby (non-rails) app that actually loaded a Rails app (from a config/environment.rb load) as well as some gems that referenced json. This caused me huge headaches due to the fact that I could not simply alter the Rails app's environment.rb file. I ended up forking a number of gems in order to get json to work without raising the dreaded TypeError: wrong argument type Hash (expected Data) message.

I had some luck with this solution, which is exactly the opposite as the community wiki's answer above... http://blog.swivel.com/code/2009/03/active-support-and-json-gems-dont-play-nice.html which basically advocates calling require 'active_support' BEFORE require 'json'

This was the only way I could make it work, and believe me I tried everything over many months.

Answer 6

I've yet to try it, but it looks like Rails 2.3.3 gives you some control:

ActiveSupport::JSON.backend = 'JSONGem'

Found here