FA is my FlightAware authentication object, I’m able to use allAirports (e.g. @airports = FA.allAirports(AllAirportsRequest.new)), so the problem is not with my FlightAware config/init, but the error message I’m getting is:
I get this error message no matter what ICAO airport code I use as a parameter. Any clue what is going on here? Looking at the Ruby driver (github.com/flightaware/flightxm … ghtXML2.rb) it looks like this should work?
Why would “AirportInfo” be a valid method for you and not me, and since it is clear that a string like “KHOU” should work, what’s up with the invalid airport error? Puzzling…
bovineone, if you could kindly post a complete example that includes the declaration of your $fxml, that would be tremendously helpful. I’m still having problems tracing down the source of my problem here. If your $fxml is equivalent to:
I tried it but I didn’t get that far because the soap4r people have seemingly renamed/moved some functionality since that flightxml2-client-ruby github package was written and it no longer runs for me on my dev machine. soap4r was originally lacking some internal plumbing needed for HTTP Basic-Auth support and it was rather suboptimal to begin with. That github package probably needs to be rewritten to be compatible with modern soap4r versions. Maybe they support Basic-Auth natively now? Maybe those Client+Driver files just need to be regenerated? You’re welcome to try to revamp it and submit a pull-request to our github project if you figure out the soap4r method.
Hmmm… Or, maybe instead of Gemfiles pulling from the soap4r Github head, they should pull an older certain tagged release until this stuff can be sorted out?
Up until this point my Gemfile included the following:
Maybe instead I should have made a Soap4r Git submodule, checked out an older version, and linked against that? I’m going to try the Savon library now, but if I have time I might circle back and experiment with this a little bit. If there are no problems with the Savon library perhaps you’d decide it would be easier to abandon the soap4r driver altogether, but I’d expect that figuring out what version caused things to break would be the lower hanging fruit for your existing developers using the soap4r library who aren’t ready to jump ship?