The anatomy of a delphi crash

Delphi has the habit of crashing on exit from time to time. This time it was quite resourceful in finidng different styles of error-messages:

Harmless
Quite ordinary

Overlay
Overlay

Transparent
Transparent

Captionless
And finally: Captionless

New messages popped out just after closing the previous one with “OK”. Finally I had to close the delphi32.exe process using the Task Manager. Delphi would be the perfect piece of software if only it’d be more stable.

What I dislike about Java

I really tried to get into programming something in Java. Alone the psossibilities with JSP/Servelets seem very interesting compared to what you get when using PHP. Another thing would be the many excellent IDE’s (even free ones like Eclipse) out there that only support java (I know that PHP-Plugins for Eclipse exist, but they are not really usable – a thing I’ll write about in the future).

But I never really took off and until today I never really could describe what is holding me back.

Today I found this article which explains it by using examples to compare python to java. Although it’s about python (a language I don’t really like), most of the point in there apply to other scripting languages (PHP, Perl, Ruby,…) too.

Really good read and finally the explanation I was looking for.

SOAP needs soap

For our Web-Portal superspeed, I am working on a webservice to give some clients access to our provider/offer database.

As the whole portal is written in PHP, I deceided to write the Webservice (fully fledged using the SOAP-Protocol) in PHP too. After some searching, found NuSOAP and the SOAP-Package in PEAR.

Both packages have virtually no documentation, but the PEAR-package has some nicely documented samples (disco_server.php, example_server.php just to name the most interesting two).

While nuSOAP is very easy to handle, it doesn’t have a way to autogenerate WSDL-output which would have forced me to learn writing WSDL. Unfortunatly I did not have time for this, so I went with the PEAR-Package which is able to create the WSDL for you.

The first tests using PHP as SOAP client worked very well.

tip: to increase “debugability” to an actually useful level, use something like the code here for debugging your server:

// include the actual server class
require_once 'modules/ss3_Provider/xml_access.php';

if ($_SERVER['argv'][1] != 'direct'){
    // use the SOAP-Interface to our class
    include("SOAP/Client.php");
    $wsdl = new SOAP_WSDL("http://your.server.com/server.php?wsdl");
    $object = $wsdl->getProxy();
}else{
   // Use the class directly
    $object = new CProvServiceInfo_Class();
}
// do something with $object

If the script is called with the “direct” parameter, the class will be used directly thus giving you back all the debug information you need without an XML-parser trying and failing to unserstand them.

As the customer for this service is going to use ASP.NET to access the webservice, the next step was to try accessing the service via Visual Studio.NET. This was not fun (pasting the complete error here in the hope that google will catch this and will help future users having my problem):

Custom tool warning: At least one import Binding for the ServiceDescription is an unsupported type and has been ignored.

The hairy thing: I have no expirience at all with VS.NET, so I first thought this was a minor problem and I was just too stupid to actually use the imported class. But sooner or later (after trying out importing the Google Webservice), I came to the conclusion that this warning actually is a grave error: Nothing got imported. Nothing at all.

Searching google did not yield any results.

The next step for me was to learn WSDL (which I did not want to in the first place ;-). Unfortunatly, the PHP generated WSDL-File seemed quite ok (besides the missing <documentation>-Tags).

I could not get VS to report a mor detailed/useful error message.

Just when I wanted to give up, i thought of this tool, wsdl.exe that gets installed with the .NET Framework SDK. Running wsdl <filename.wsdl> gave me the same error message, but with a note to look into the generated .cs-File.

This finally gave an usable error-message:

// CODEGEN: The binding 'SuperspeedProvidersBinding' from namespace 'urn:SuperspeedProviders' was ignored. There is no SoapTransportImporter that understands the transport 'http://schemas.xmlsoap.org/soap/http/'.

A quick comparison of the <soap:binding&gt-Tags showed:

Googles Version: http://schemas.xmlsoap.org/soap/http
PHP’s Version: http://schemas.xmlsoap.org/soap/http/

Note the slash at the end.

I hate problems with simple solutions that are so awfully difficult to find because of un-usable error messages!

Just for reference: The following patch fixes the wrong Transport-URL in PEAR::SOAP (0.7.3 – I will report this to the author, so maybe it’s fixed in later versions):

--- Base.php    Thu Jun  5 13:16:03 2003
+++ -   Fri Jun  6 22:51:08 2003
@@ -91,7 +91,7 @@
 define('SCHEMA_DISCO_SCL',          'http://schemas.xmlsoap.org/disco/scl/');

 define('SCHEMA_SOAP',               'http://schemas.xmlsoap.org/wsdl/soap/');
-define('SCHEMA_SOAP_HTTP',          'http://schemas.xmlsoap.org/soap/http/');
+define('SCHEMA_SOAP_HTTP',          'http://schemas.xmlsoap.org/soap/http');
 define('SCHEMA_WSDL_HTTP',          'http://schemas.xmlsoap.org/wsdl/http/');
 define('SCHEMA_MIME',               'http://schemas.xmlsoap.org/wsdl/mime/');
 define('SCHEMA_WSDL',               'http://schemas.xmlsoap.org/wsdl/');

As you can see, there are more URLs having a slash at the end – possibly more candidates? We’ll see. At least I know now, how to debug such problems…

Two more bugs… gone!

No. This is not about the new iPods, Apple announced today (of course I’ve ordered myself a 30GB one, but this really is another history).

I’m just very pleased that two Bugs in jEdit’s current CVS-Version that have been fixed by Slava the same day, I’ve reported them. This is just great!

If you are in need of a good editor, go and get jEdit!