-
Notifications
You must be signed in to change notification settings - Fork 615
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
message_tag issue #529
Comments
Hey @dsshap, thanks for opening this issue and reminding me that we need to address this soon. We just shipped out Savon v2.3.1 and I think it would be great to issue another small dot release that fixes this issue too. I haven't had time to sit down and investigate this fully, but from what I've read, this regression was introduced by a change in Wasabi, for issue savonrb/wasabi@a68840b. My current plan is to do some testing around that one commit and if that did introduce the regression, revert it, bump the version number and ship a new version to rubygems.org It seems like using Savon v 2.2.0 (any version before 2.3, really) would be a convenient workaround in the meantime. |
Hey @tjarratt, happy this is back on your radar. I have a little meta programming around this, so its not a pressing issue for me. Side note, I did revert back to 2.2.0, but still saw the issue. Granted I reverted for a moment and probably didn't give it enough love. Also, In the API i posted above I was seeing an issue with param ordering. In GET calls the order of parameters didnt matter, but on SETs if the order wasn't maintained the server was throwing 500. I understand the server i am accessing is Cold fusion, but i have a feeling something might be set differently in their configurations. I developed a work around but it would be a cool feature is the framework took care of the ordering for us (maybe something in v3). |
There's another open issue around order of params sent in requests, so it sounds like we'll need to add that to the v3 features. Actually, I took a quick look at the unfinished work for v3.0.0, and it's actually on the list! #473 Keeping this issue open for now to remind me that we need to fix this issue in Savon 2.3.x asap |
@paracycle was kind enough to track down these changes. I believe these changes may be valid for Output, but almost certainly not for Input. I had an opportunity to speak with @rubiii earlier about this and his thoughts were that it wasn't very surprising that this change broke a lot of real code. For one, it also changed specs. Secondly, there wasn't a real example of why this would need to be like this in the PR. Lastly, the end result of the code is overly complicated. I've just spent the last hour looking at the `input_output_for` method in Wasabi::Parser just to find out that this was pulling in a completely bogus request / response tag name in two thirds of the cases. My hopes are that this fix will fix the regression in Savon 2.3.x and we can stop worrying about this for Savon v3.
@dsshap I'm fairly that this issue has been resolved. Would you mind taking a look at this with Savon 2.3.2 and Wasabi 3.2.3? If you're just using Savon in your Gemfile, you should be able to Please re-open this issue if I'm mistaken and this bug is in fact still present. |
The documentation mentioned to open a ticket if I needed to use message_tag.
Well I had to ;)
the wsdl i am using is this:
http://65.115.229.212/services/copalink.cfc?wsdl
savon 2.3.0 was causing the message_tag to appending 'xxxRequest'.
I noticed that there was an open issue for it here: #482
but there was no solution mentioned.
If there is a better solution I am all ears...
The text was updated successfully, but these errors were encountered: