unwire / handsoap
- Source
- Commits
- Network (2)
- Issues (2)
- Downloads (35)
- Wiki (5)
- Graphs
-
Branch:
master
-
Hi,
in the method Fault.from_xml in lib/handsoap/service.rb the namespace selector is partially missing, ie. instead of
fault_code = node.xpath('./faultcode', ns).to_sit should probably be
fault_code = node.xpath('./env:faultcode', ns).to_sSame with
faultstringanddetail.Best regards,
ThomasComments
-
Gem Building is Defunct. Please see http://github.com/blog/515-gem-building-is-defunct
Please push to gemcutter (http://gemcutter.org/) instead.Comments
thanks for the heads up. We are currently looking into the issue
Gem is now at: http://gemcutter.org/gems/handsoap
-
Some services require a session-cookie to be maintained between requests, for instance [1].
I've created a small change to the Curb connector to support this. Please pull from:
http://github.com/rud/handsoap/tree/reuse-curb-instance[1] https://www.e-conomic.com/secure/api1/EconomicWebService.asmx
Comments
Btw, to enable cookie support for the curb driver, add the following to your initializer after applying the patch:
Handsoap.http_driver = :curb
Handsoap::Http.drivers[:curb].http_client.enable_cookies = trueThe relevant feature-adding commit is this: http://github.com/rud/handsoap/commit/acaa5f5ec94147a752cde5d001ccebb9b6c516c3
Since the refactoring to enable async http, this patch can't be applied directly. I've integrated it manually instead. Notice that I made some changes; I do not like to let the driver maintain state by default, as this could lead to some very hard-to-track-down bugs. To use it, you'll have to override the method
http_driver_instancein your service class. Eg.:class MyService < Handsoap::Service def http_driver_instance unless @driver_instance @driver_instance = Handsoap::Http.drivers[Handsoap.http_driver].new @driver_instance.enable_cookies = true end @driver_instance end endCurrently, only the
curbdriver implements support forenable_cookies, although I assume the other drivers have similar capabilities (or it could be implemented in the abstraction layer)I suspected you had a reason for creating new instances for each request, even though it clashed with my use-case.
Your suggested service-change is clean and explicit - I'll be integrating it in my service shortly.
Thank you for the quick feedback and integration! :)
-
Hi,
although the last change of the gemspec is many hours ago, no 1.0.0 gem has been built.
Best regards,
ThomasComments
Just found the "track build progress" page: http://hasmygembuiltyet.org/unwire/handsoap
It seems that github no longer supports building gem.
This was pointed out here: http://github.com/unwire/handsoap/issues#issue/5 (this issue also has a deep link to the actual github blog post)We'll try to keep both issues up-to-date, and will try to get the new gem up asap
Gem is now at: http://gemcutter.org/gems/handsoap
-
Hi,
when using REXML as query driver there is a problem when using
#to_son an element returned by an XPath withtext()like./ns:Element/text()since the returned REXML element is of type REXML::Text which does not have a#textmethod. However, the text value can be returned by using the#valuemethod. So an additional check for the REXML::Text element is needed.Best regards,
ThomasComments
-
Feature request: Add a few basic DOM operations to XmlQueryFront
3 comments Created 2 months ago by gcampbellIn one of my Handsoap usecases, I'm retrieving a large set of DataPoint nodes, each with timestamp and value as child nodes, as follows:
<DataPoint> <timestamp>2009-10-07T12:30:00</timestamp> <value>5</value> </DataPoint>As I understand it, the only way to individually retrieve the timestamp and value nodes for each DataPoint is through XPath, which is a relatively heavyweight operation compared to simple retrieval of both child nodes for a use case like this. Simply adding a "children()" method would probably be sufficient.
I may end up adding this in myself, of course, but just wanted to "officially" put it out as a suggestion.
Comments
By heavyweight, I assume that you mean raw performance? If that is the case, did you actually measure the difference between dom traversal and xpath querying? My gut feeling is that the difference is much smaller than you might think. In the case of xmllib/nokogiri, the xpath querying happens in the external library, which is presumably quite efficient. Traversing the dom would potentially be more intensive than querying. Now, I don't have any metrics, so this is just my best guess, but I would suggest that you measure it. Even if traversal is faster, you would probably need very large datasets for it to matter; The time taken to parse the xml and in the http-layer will most likely dwarf it by comparison.
That said, an xpath query offers a level of abstraction, which is probably better for your application design. With traversal, you have a tendency to make assumptions about the structure of the xml, so if it changes your application may break easier.
I agree that hard numbers are useful for this sort of thing, so following is my benchmark:
user system total real DOM 4.920000 0.200000 5.120000 ( 6.703107) xpath 16.030000 0.290000 16.320000 ( 18.201955)This was for a dataset of two weeks of one-minute data, thus 20160 data points. For the DOM solution, I used native_element to get at the underlying Nokogiri nodes. My use case may be atypical, of course, and I'm not worried about cross-XML-library compatibility for this particular code, so I can understand if you'd prefer to leave this sort of thing out of the API.
I must say, that was a bigger difference than I expected. Probably because you are calling xpath twice, thereby hitting the external api twice, rather than just one call to
#children. I've added a#childrenmethod to the api now, so you can use it without sacrificing portability.





Hello,
After looking at http://schemas.xmlsoap.org/soap/envelope/ it seems that the current implementation is ok.
Remember that all this is depending on you using SOAP1.1 not SOAP1.2 (SOAP1.2 specs: http://www.w3.org/TR/soap12-part1/#soapfault)
Hmm... I'm not good at reading XSD files but where does it say that the child elements
faultcode,faultstringanddetailofFaultdon't live in the same namespace? For example, is the following not a vaild fault response:This is what is returned by an Intel AMT 5.0 device. As you can see, the child elements are properly namespaced. But since the current implementation only checks for unnamespaced child elements, the correct information is not read out. For example, you have
and explicitly specify the namespace as second argument to the
#xpathmethod but you don't use the defined namespaceenvin the first argument. This seems odd...Could you shed some light on this?
The SOAP returned, from your INTEL machine, seems fine.
I'm currently making some tests for this issue and getting some more qualified people to look at my solution.
Just to let you know that there is progress on the issue.
Thanks! Just so you know: when changing the path to include the env namespace, ie.
./faultcodeto./env:faultcode, the faults from my test machine are reported correctly.True, but the tests fail.
This is now fixed in version 1.1.2
Thanks!