Savon does not always handle :content! correctly

[bmattei]

If Savon is initialized with element_form_default: :qualified (the default) it converts the hash key: :content! to "content!".

Gyoku understands :content! as a keyword indicating the value associated with the key is the content of the element. When it is converted to "content!" it loses it's meaning to Gyoku.

Changed
Savon.client(wsdl: @wsdl_path,
encoding: "UTF-8",
env_namespace: :soapenv, namespace_identifier: :ns,
namespaces: {"xmlns:ns" => "http://www.endeca.com/MDEX/conversation/services/types/3/0",
"xmlns:ns1" => "http://www.endeca.com/MDEX/conversation/XQuery/2009/09"},
raise_errors: false,
log_level: :debug
)

to
Savon.client(wsdl: @wsdl_path,
encoding: "UTF-8",
env_namespace: :soapenv, namespace_identifier: :ns,
namespaces: {"xmlns:ns" => "http://www.endeca.com/MDEX/conversation/services/types/3/0",
"xmlns:ns1" => "http://www.endeca.com/MDEX/conversation/XQuery/2009/09"},
raise_errors: false,
element_form_default: :unqualified,
log_level: :debug
)

To work around the problem.

Found the issue by setting a break point in
message.rb#to_s.

• After calling QualifiedMessage.new(@types, @used_namespaces, @key_converter).to_hash(@message, [@message_tag.to_s])

any :content! key is converted to "content!"

[shkigor]

I've the same issue if I create new client and invoke call method.
Just for note, :content! option was worked on the Savon version '2.2.0'

client = Savon.client do
   wsdl ...
end
response = client.call(:create_token, message: {
        :user => userName,
        :param => {
            :@name => "shopId",
            :content! => shopId
        }
    })

When I use class which extend Savon::Model
:content! option is worked succesfully on the Savon version (2.11.1)!!!

class User
  extend Savon::Model

  client endpoint: ...
  def self.create_token(userName, shopId)
    super(message: {
        :user => userName,
        :param => {
            :@name => "shopId",
            :content! => shopId
        }
    })
  end
end

[pcai]

Thanks for reporting this. I believe this is fixed in #676 which is released in v2.11.2 - can you give this a try and reopen if you find an issue? Thanks!