Cause: coldfusion.xml.rpc.ServiceProxy$ServiceInvocationException: Cannot perform web service invocation Enroute.
Diagnostics: Cannot perform web service invocation Enroute. The fault returned when invoking the web service operation is:
org.apache.axis2.AxisFault: Transport error: 503 Error: Service Unavailable
at org.apache.axis2.transport.http.HTTPSender.handleResponse(HTTPSender.java:310)
at org.apache.axis2.transport.http.HTTPSender.sendViaPost(HTTPSender.java:194)
at org.apache.axis2.transport.http.HTTPSender.send(HTTPSender.java:75)
at org.apache.axis2.transport.http.CommonsHTTPTransportSender.writeMessageWithCommons(CommonsHTTPTransportSender.java:402)
at org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:231)
at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:443)
at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:406)
at org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:229)
at org.apache.axis2.client.OperationClient.execute(OperationClient.java:165)
at com.flightaware.flightxml.soap.flightxml2.FlightXML2Stub.enroute(FlightXML2Stub.java:9306)
at sun.reflect.NativeMethodAccessorImpl.i… ‘’**
Since Cold Fusion is just using Apache Axis for the underlying SOAP requests, you might be able to enable its logging to find out more about what is happening:
Just to keep you updated, we’ve been doing some additional testing against CF10 here and we can confirm the problem you’re seeing. It looks like the new version of Cold Fusion does not allow the HTTP Basic authentication information to be passed on in the SOAP webservice POST requests any more, even though the username/password elements are still supported arguments for the webservice object.
We would recommend submitting a bug to bugbase.adobe.com/ against Cold Fusion, however their bugbase appears to currently be experiencing server issues.
We are also investigating modifying our FlightXML servers to alternatively support authentication information supplied within the SOAP envelope, but this is still just under evaluation for technical feasibility.
I don’t recall if ColdFusion 8/9 used Axis1 or Axis2… However, if it used Axis1 and they upgraded to Axis2 in ColdFusion 10, it’s possible that Adobe did not notice that the password authentication for Axis2 requires a different hook. If you compare the Java Axis1 and Java Axis2 examples on flightaware.com/commercial/flig … ation2.rvt you’ll see that HttpTransportProperties.Authenticator must now be used to pass the credentials for Axis2. Adobe would need to be using that new method if they want to allow HTTP Basic authorization webservices continue to work in ColdFusion 10.
Feel free to post the URL to your Adobe bugbase report once you open it.
It might be easier to get support for ColdFusion 11 since that is the current version, however we’ve tested your problem to confirm that it also still occurs with CF11.
It hasn’t been removed, but FlightXML1 has a different backend SOAP implementation than FlightXML2 which may have different compatibility constraints with some SOAP clients.
I would advise not developing against FlightXML1 if possible, since we are planning to deprecate it in the next 12 months (future announcement forthcoming). Instead, trying to do manual formed and parsed JSON requests against the FlightXML2 (rather than SOAP) might be one other possibility.
Do you have any influence with Adobe? Can FlightAware ask Adobe to address this issue? It’s completely stopping my efforts to implement XML2. Thanks for any help.
Unfortunately, we don’t have any special relationship with Adobe at this time that would let us easily prioritize this as an issue for them. We are planning a workaround on our side that might be able to get this usage working for you specifically, but I can’t estimate when we’ll have it ready yet.