Using Soap and Other Standard Libraries in Ruby 1.9.2

Using SOAP and other Standard Libraries in Ruby 1.9.2

If you want to keep using Ruby 1.8's standard soap library (aka soap4r), you can try https://github.com/spox/soap4r-spox ...

wget --no-check-certificate https://github.com/spox/soap4r-spox/tarball/1.5.8.4
tar -xzf spox-soap4r-spox-1.5.8.4-0-g345a6cb.tar.gz
cd spox-soap4r-spox-345a6cb/
ruby setup.rb all

If you're using rvm, don't sudo the last command... instead su into root and rvm to ruby 1.9 so that setup.rb puts the files into the right place.

$ irb
ruby-1.9.2-p0 > require 'soap/rpc/driver'
 => true 
ruby-1.9.2-p0 > require 'xsd/qname'
 => false 
ruby-1.9.2-p0 > require 'soap/wsdlDriver'
 => true 
ruby-1.9.2-p0 > require 'fileutils'
 => true 

As suggested by other StackOverflow answers, you might want to switch to a gem like savon.

rails 2.3.8 + actionwebservice + ruby 1.9.2 problem

The soap driver that was available in ruby 1.8 has been removed in ruby 1.9

You'll need to build soap for ruby 1.9 yourself as outlined in this answer: Using SOAP and other Standard Libraries in Ruby 1.9.2

soap client for ruby 1.9 and rails

Savon abstracts the XML part into a Ruby Hash. Have a look: http://github.com/rubiii/savon

How do I move from SOAP:RPC:Driver to Savon

When not using a WSDL one must set up wsdl explicitly (I find this a little counter-intuitive, but it works):

require 'savon'
client = Savon::Client.new do
    wsdl.endpoint = 'http://example.com/endpoint'
    wsdl.namespace = 'MY_NAMESPACE'; 
end

I don't believe there is an equivalent to add_method in Savon, but you should then be able to make a request thus:

response = client.request 'MyMethod' do
  soap.body = { 'Arg1' => arg_one' }
end

However when I did this I received the following error:

Savon::SOAP::Fault: (SOAP-ENV:Client) SOAPAction shall match 'uri#method' if present 

I was able to work around this by explicitly setting SOAPAction:

response = client.request 'MyMethod', soap_action: '#MyMethod' do ...

Finally I got this error:

Savon::SOAP::Fault: (SOAP-ENV:Client) Denied access to method (MyMethod) in class (main) at /usr/lib/perl5/site_perl/5.8.8/SOAP/Lite.pm line 2128.

This seems to be because the given wsdl.namespace isn't passed as expected with the request. I was able to resolve this by explicitly setting it in both soap_action and xmlns:

response = client.request 'MyMethod', soap_action: 'MY_NAMESPACE#MyMethod', xmlns: 'MY_NAMESPACE'

What will the major/minor differences be between ruby 1.9.2 and ruby 2.0?

Two features that are already implemented in YARV, and which will most likely end up in Ruby 2.0, are traits (mix) and Module#prepend.

The mix method, unlike the current include method, takes a list of modules, and mixes all of them in at the same time, making sure that they have no conflicting methods. It also gives you a way to easily resolve conflicts, if e.g. two modules you want to mix in define the same method. So, basically, while the include method allows you to treat a module as a mixin, the mix method allows you to treat a module as a trait.

Module#prepend mixes a module into a class or module, again just like include does, but instead of inserting it into the inheritance chain just above the class, it inserts is just below the class. This means that methods in the module can override methods in the class, and they can delegate to the overriden methods with super, both of which is not possible when using include. This basically makes alias_method_chain obsolete.

One feature that has been discussed for a couple of months (or 10 years, depending on how you count), are Refinements. There has been discussion for over 10 years now to add a way to do scoped, safe monkey patching in Ruby. I.e. a way where I can monkey patch a core class, but only my code sees that monkey patch, other code doesn't. For many years, the frontrunner for that kind of safe monkey patching were Selector Namespaces, however more recently, Classboxes have been getting a lot of attention, and even more recently, a prototype implementation and specification of Refinements, a variant of Classboxes, was put forward.

Generally speaking, the big theme of Ruby 2.0 is scalability: scaling up to bigger teams, bigger codebases, bigger problem sizes, bigger machines, more cores. But also scaling down to smaller machines like embedded devices.

The three features I mentioned above are for scaling to bigger teams and bigger codebases. Some proposed features for scaling to bigger problem sizes and more cores are parallel collections and parallel implementations of Enumerable methods such as map, as well as better concurrency abstractions such as futures, promises, agents, actors, channels, join patterns or something like that.

How to surpress strange stdout message when using Ruby and SOAP

You can squelch stdout by redirecting it to /dev/null:

commandname >/dev/null

You can squelch stderr by redirecting it to /dev/null:

commandname 2>/dev/null

You can squelch both stdout and sderr by redirecting both to /dev/null:

commandname &>/dev/null

However these methods would squelch any genuine errors your script might be giving.

A somewhat a better option is to let nohup run your script and redirect the output (both stdout and stderr) to nohup.out:

nohup commandname

... this way your cron won't receive any errors (and won't send an error email to you), but you can still periodically check for the contents of nohup.out, just make sure it gets created in the proper directory (maybe nohup has options for that, lacking that you'll have invoke nohup from the particular directory where you want nohup.out to be created).

But even better would be to just suppress this single line using grep:

commandname | grep -v 'ignored attr: {}abstract'

... (make sure you use proper shell escaping there, I just put it between apostrophes '' but the braces {} might need other escaping) this way you only suppress occurences of this particular message from stdout, but let all other messages get through. so you won't get an email if this is the only kind of thing emitted by your script, but you will get email if the script outputs other messages - which I guess is pretty close to what you want.

Perfect solution of course would be to delve into the script and find and fix what is causing the message.

undefined method `copy' for File:Class

It should actually be FileUtils.copy or FileUtils.cp. I wonder how your old project worked with just File.copy, as File doesn't have that method.

refer here: http://santoro.tk/mirror/ruby-core/classes/FileUtils.html#M004325

---

Related Topics