Uninitialized constant when using 1.5.8 with Rails

Hi,

Please see http://dev.ctor.org/soap4r/wiki#Gem and add the following 2 lines *at the top of* config/environment.rb

require 'rubygems'
gem 'soap4r'

http://groups.google.co.jp/group/soap4r/msg/309fa2f9a23c1471?dmode=source may help you on the same problem about rake + rails.

I think this is a more serious problem than it may seem. The issue is that if you install this new SOAP4R gem, it will break every single Rails project that does not have the above changes to environment.rb. This isn't so bad if the project actually uses SOAP4R, but when you have to change every Rails project on the system.... that seems like a problems. A standalone gem should not break other apps that aren't evening using it (IMHO).

While this isn't really a SOAP4R problem so to speak... it's certainly not playing nice with Rails apps. And I'm guessing this Rails autoload "feature" isn't going to change anytime soon...

It's even worse than breaking every single Rails project that doesn't have that in the environment.rb

It breaks the "rails" script for generating new Rails applications as well:

$ rails foobar /opt/local/lib/ruby/gems/1.8/gems/activesupport-1.4.2/lib/active_support/dependencies.rb:477:in `const_missing': uninitialized constant XSD::NS::KNOWN_TAG (NameError?)

from /opt/local/lib/ruby/gems/1.8/gems/soap4r-1.5.8/lib/soap/ns.rb:18

Please claim this to Rails community. There's nothing soap4r can do.

A simple (albeit non-DRY) fix is to change the KNOWN_TAG definition in soap/ns.rb to the following:

class NS < XSD::NS

KNOWN_TAG = {

XSD::Namespace => 'xsd', XSD::InstanceNamespace? => 'xsi', SOAP::EnvelopeNamespace? => 'env'

}

This seems like a trivial case of ActiveSupport? kicking in before everything has properly loaded.

I doubt Rails core is going to do anything about it, and it would require everyone to update Rails in order to fix it.

Hi,

The problem is caused by;

• Ruby's feature loading system (Kernel#require), plus
• RubyGems?' hacking to control the feature loading scheme, plus
• Rails' hacking to improve performance of the feature loading

It's caused by Rails + RubyGems? and soap4r just hits the problem. For now soap4r is the only module that is bundled with Ruby and released as a gem. When another module such as REXML, yaml and so on will try to create a gem, same kind of problem must be exposed. The only workaround works now is declaring soap4r gem ('gem "soap4r"') before Rails tries to load any features.

posted to ruby-talk: http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/271737

The ruby-talk link seems to be broken, so here is a repost of NaHi's comments on this thread which have some good work-around suggestions:

Eric H. wrote:
>  Seems this was caused by soap4r-1.5.8, removing it and using only 1.5.7
>  fixed the problem. I happened to do a search and found that someone was
>  having problems starting Mongrel if they had 1.5.8 installed so I tried
>  it and viola! it worked.

soap4r-1.5.6, soap4r-1.5.7 did not work as expected, too.

The problem is caused by;

 * Ruby's feature loading system (Kernel#require), plus
 * RubyGems' hacking to control the feature loading scheme, plus
 * Rails' hacking to improve performance of the feature loading

It's caused by ActiveSupport + RubyGems, and soap4r just hits the
problem.  For now soap4r is the only module that is bundled with Ruby
and released as a gem.  When another module such as REXML, yaml and so
on will try to create a gem, same kind of problem must be exposed.

Workaround of this ActiveSupport + RubyGems problem;

 1. declaring soap4r gem ('gem "soap4r"') before Rails tries to load any
    features, or
 2. sudo rm -rf /usr/local/lib/ruby/1.8/{soap,wsdl,xsd}

Regards,
// NaHi

Thanks for posting this. It's said that blade.nagaokaut.ac.jp is down by machine crash.

Is there any reason you won't modify soap/ns.rb in the way I suggested that avoids the problem?

I'm working with an application being developed by multiple developers and deployed on multiple servers.

This is the bit that's causing it to break:

KNOWN_TAG = XSD::NS::KNOWN_TAG.dup.update(

SOAP::EnvelopeNamespace? => 'env'

)

And all of that seems to be to avoid duplicating the XSD::Namespace => 'xsd' and XSD::InstanceNamespace? => 'xsi' keys in the KNOWN_TAG hash

It would be *extremely* helpful from the purposes of both deployment and maintenance if we didn't have to modify the Ruby installations of every single system we plan on using this application on, or modify every single Rails application to require soap4r in environment.rb

We have applications which do not use SOAP deployed on systems which won't have soap4r installed, for example, and doing an explicit require_gem 'soap4r' in applications we aren't using soap4r on just because we have the soap4r gem installed.

This seems like much ado over two little hash keys...

Hi,

There's a clear reason why I can't apply the patch. As I wrote in [ruby-talk:271737] (you can see it at http://dev.ctor.org/soap4r/ticket/433#comment:9 too), patched soap4r-1.5.8, soap4r-1.5.7, and soap4r-1.5.6 all won't work as expected though you've seen no problem yet. Rails are loading xsd/ns.rb in soap4r-1.5.5 and soap/ns.rb in soap4r-1.5.[678] in such an environment.

I cannot support this kind of version mixing environment.

I'm not suggesting that in lieu of doing require_gem 'soap4r' before Rails itself loads. I'm suggesting doing that to avoid breaking Rails-related things when soap4r isn't in use.

There won't be a problem with mixed versions as long as the first line of environment.rb is require_gem 'soap4r', correct?

If so, why not make sure the soap4r gem doesn't break Rails when it isn't in use?

Hi,

Because Rails (dependency.rb in ActiveSupport?) wrongly loads mixed versions. It's simply an issue of Rails.

In that case, wouldn't it be better to raise an informative exception when a mixed environment is detected, rather than having it fail on this rather obscure error?

I know what you meant but please ask to ruby on ruby-core or rubygems on rubygems-ml. Not related to soap4r.

Ruby on Rails is garbage. I am going back to Java. Thanks, Nahi, and the rest of you sadists.

This is a pretty serious problem for the Ruby community... anyone coming in right now trying out Ruby for the first time in an enterprise context (more likely than not by way of Rails) is going to walk away in frustration.

Nahi, I would strongly suggest that you put away the argument about who's right vs. who's wrong for the moment, and just accept the patch. You're right of course that in the future this is going to have to be fixed in activesupport, not in soap4r, but please try to be a bit more pragmatic about this. Forcing the Rails team to fix something on their end by pushing into production a show-stopper conflict might not be the most productive (mature?) way to go about this.

FYI, in the example you provided, it printed with a ? at the end of the XSD::InstanceNamespace? like XSD::InstanceNamespace??

Need to remove those question marks for the fix to work...

Replying to user:

A simple (albeit non-DRY) fix is to change the KNOWN_TAG definition in soap/ns.rb to the following: class NS < XSD::NS KNOWN_TAG = { XSD::Namespace => 'xsd', XSD::InstanceNamespace? => 'xsi', SOAP::EnvelopeNamespace? => 'env' } This seems like a trivial case of ActiveSupport? kicking in before everything has properly loaded. I doubt Rails core is going to do anything about it, and it would require everyone to update Rails in order to fix it.

Rails + soap4r expert can create a right patch which does not introduce another problem (version mix).