PayPal Soap Anbindung

[TiGü]

Zitat von makulik:

Leider ist es so, dass tatsächlich Embarcadero den Fehler (das Memory-Leak) verursacht.

Das Problem ist der folgende Code in der Funktion TSOAPDomConv.ConvertSOAPToObject aus Soap.OPToSOAPDomConv.pas ab Zeile 4768:

Delphi-Quellcode:

function  TSOAPDomConv.ConvertSOAPToObject(RootNode, Node: IXMLNode; AClass: TClass;
  const URI, TypeName: InvString; ObjP: Pointer): TObject;

// ...
    if Assigned(Obj) and LegalRef then
    begin
     if (NodeClass <> nil) and (NodeClass <> Obj.ClassType) then
        Obj.Free(); // Dieses Free hat gefehlt, die alte Instanz von Obj dangled nach dem Überschreiben
        Obj := NodeClass.Create;
    end

// ...

Ist auch in der aktuellen Delphi Version (Tokyo) noch vorhanden. Vermutlich gibt es auch noch weitere Stellen die ein ähnliches Problem haben.
TObject ist nun mal nicht ref-counted
Ich werde ein Ticket bei Embarcadero aufmachen.

Gruss,
Günther

Wenn man sich in der Methode den XML-Text vom RootNode anschaut sieht man folgendes:

Code:

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:cc="urn:ebay:apis:CoreComponentTypes" xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext" xmlns:ed="urn:ebay:apis:EnhancedDataTypes" xmlns:ebl="urn:ebay:apis:eBLBaseComponents" xmlns:ns="urn:ebay:api:PayPalAPI">
   <SOAP-ENV:Header>
      <Security xmlns="http://schemas.xmlsoap.org/ws/2002/12/secext" xsi:type="wsse:SecurityType"/>
      <RequesterCredentials xmlns="urn:ebay:api:PayPalAPI" xsi:type="ebl:CustomSecurityHeaderType">    <<<--------- Hier ist der Übertäter
         <Credentials xmlns="urn:ebay:apis:eBLBaseComponents" xsi:type="ebl:UserIdPasswordType"/>
      </RequesterCredentials>
   </SOAP-ENV:Header>
   <SOAP-ENV:Body id="_0">
      <RefundTransactionResponse xmlns="urn:ebay:api:PayPalAPI">
         <Timestamp xmlns="urn:ebay:apis:eBLBaseComponents">2018-06-14T11:41:34Z</Timestamp>
         <Ack xmlns="urn:ebay:apis:eBLBaseComponents">Failure</Ack>
         <CorrelationID xmlns="urn:ebay:apis:eBLBaseComponents">ac2341fd2df09</CorrelationID>
         <Errors xmlns="urn:ebay:apis:eBLBaseComponents" xsi:type="ebl:ErrorType">
            <ShortMessage xsi:type="xs:string">Authentication/Authorization Failed</ShortMessage>
            <LongMessage xsi:type="xs:string">You do not have permissions to make this API call</LongMessage>
            <ErrorCode xsi:type="xs:token">10002</ErrorCode>
            <SeverityCode xmlns="urn:ebay:apis:eBLBaseComponents">Error</SeverityCode>
         </Errors>
         <Version xmlns="urn:ebay:apis:eBLBaseComponents">0.000000</Version>
         <Build xmlns="urn:ebay:apis:eBLBaseComponents">000000</Build>
         <RefundTransactionID/>
      </RefundTransactionResponse>
   </SOAP-ENV:Body></SOAP-ENV:Envelope>

Aufgrund von

Code:

xsi:type="ebl:CustomSecurityHeaderType"

wird ja in den Zeilen

Delphi-Quellcode:

  GetElementType(ObjNode, NodeURI, NodeTypeName);
  NodeClass := RemTypeRegistry.URIToClass(NodeURI, NodeTypeName, IsScalar);

die NodeClass auf CustomSecurityHeaderType gesetzt. Mit den bekannten Folgen.

Also Workaround - welche negativen Auswirkungen das hat, muss gesondert untersucht werden - kannst du in der PayPalSvc-Unit ca. bei Zeile 28049 das folgende auskommentieren:

Delphi-Quellcode:

...
RemClassRegistry.RegisterXSClass(CustomSecurityHeaderType, 'urn:ebay:apis:eBLBaseComponents', 'CustomSecurityHeaderType');
...

Dadurch wird RemTypeRegistry.URIToClass nichts finden und NodeClass wird zu nil.
Damit bleibt das Obj (=> RequesterCredentials) erhalten und das Speicherleck ist weg.