[10.1 Berlin] Datasnap-Verbindung über HTTP nicht möglich

[DeddyH]

Ich wollte gerade mein aktuelles Projekt testhalber auf 10.1 hochziehen. Dieses verwendet eine Datasnap-Verbindung über HTTP. Leider kommt diese nicht zustande, sondern bricht mit einer ENotImplemented-Exception ab. Nach langem Debuggen konnte ich auch die Ursache ermitteln: in der Unit Data.DBXHTTPLayer besitzt die Klasse TDBXHTTPLayer eine private Property vom Typ TDSHTTPClient. Innerhalb der Open-Methode von TDBXHTTPLayer werden Timeout-Werte für diese Property gesetzt. OK, der Setter ist recht unspektakulär:

Zitat:

Delphi-Quellcode:

procedure TDSHTTPClient.SetConnectTimeout(AMilisec: Integer);
begin
  // do nothing here
end;

Leider handelt es sich aber faktisch um eine Ableitung davon, nämlich TDSHTTPNativeClient (per ClassFactory instanziert, soweit ich sehen konnte). Hier ist der Setter überschrieben:

Zitat:

Delphi-Quellcode:

procedure TDSHTTPNativeClient.SetConnectTimeout(AMilisec: Integer);
begin
                                     
  raise ENotImplemented.Create('SetConnectTimeout');
end;

Für mich heißt das also: Originalunit ins Projektverzeichnis kopieren, dem Projekt hinzufügen und die Exceptions auskommentieren, oder kennt jemand noch einen anderen Weg? Try-Except dürfte nicht helfen, da dieser Block ja viel zu weit "außen" wäre, oder?

[Uwe Raabe]

Alternativ kannst du auch die entsprechenden Timeout-Werte in den DbxProperties auf 0 setzen oder leer machen, da sie ja eh nicht verwendet werden. Leider ist TDSHTTPNativeClient private, so daß eine abgeleitete Klasse davon, die den Fehler behebt, hier nicht in Frage kommt. Du kannst natürlich die gesamte Klassenimplementation kopieren, korrigieren (z.B. die entsprechenden Eigenschaften des FHTTPClient setzen) und dann in einer Ableitung von TDBXHTTPLayer instanzieren. Diese abgeleitete Layer-Klasse wird dann mittels TDBXCommunicationLayerFactory.RegisterLayer für HTTP registriert.

Wenn du mit den Defaultwerten von 60 Sekunden leben kannst, wäre das Leeren der DbxProperties noch der einfachste Weg.

Schreibst du einen Bugreport?

[Der schöne Günther]

Zitat:

Zitat von Uwe Raabe (Beitrag 1336566)

Leider ist TDSHTTPNativeClient private, so daß eine abgeleitete Klasse davon, die den Fehler behebt, hier nicht in Frage kommt

Und bis Seattle hätte man jetzt einen

Delphi-Quellcode:

class helper

nehmen können.

(Tut mir leid, der musste jetzt sein).

[Uwe Raabe]

Zitat:

Zitat von Der schöne Günther (Beitrag 1336567)

Zitat:

Zitat von Uwe Raabe (Beitrag 1336566)

Leider ist TDSHTTPNativeClient private, so daß eine abgeleitete Klasse davon, die den Fehler behebt, hier nicht in Frage kommt

Und bis Seattle hätte man jetzt einen

Delphi-Quellcode:

class helper

nehmen können.

Wie hättest du denn in Seattle für eine private Klasse (eine, die im Implementation-Teil deklariert ist) eine Ableitung schreiben wollen und wozu bräuchte man dafür einen Class Helper? Dieses Argument zieht genau hier nicht, da die relevanten Felder eben nicht private, sondern protected sind. Das Problem ist hier lediglich die Sichtbarkeit der Klasse und nicht der ihrer Felder.

[DeddyH]

Und wenn man statt einer Exception einfach einen Hint ausgegeben hätte, müsste ich gar nichts tun, würde aber zur Designtime darauf hingewiesen, dass Timeouts nicht implementiert sind. Mal wieder prima gemacht :evil:

[Uwe Raabe]

Zitat:

Zitat von DeddyH (Beitrag 1336569)

Und wenn man statt einer Exception einfach einen Hint ausgegeben hätte, müsste ich gar nichts tun, würde aber zur Designtime darauf hingewiesen, dass Timeouts nicht implementiert sind. Mal wieder prima gemacht :evil:

Wie gesagt: Bugreport schreiben!

Timeouts sind nichtsdestotrotz implementiert - man kann die Werte nur nicht über die DbxProperties ändern, sondern muss mit den Defaultwerten Vorlieb nehmen.

[DeddyH]

Endlich nutze ich das neue QC auch mal: https://quality.embarcadero.com/browse/RSP-14296