Re: TSOAPAttachment that's not streamed...partial success.

Hello,

Not registering the class will clearly have some side-effects as by default
the SOAP runtime assumes TRemotable types are multiref'ed.

I should add that in my tests I used a TLinkedRIO as it allows me to quickly
see the request/response. If you noticed something different, please let me
know and I'll investigate. I can send you the same I put together.

Cheers,

Bruneau.

On Wed, 30 Jan 2008 04:00:01 +0100, Jean-Marie Babet <bbabet@borland.com> 

wrote:

> Hello,
>
> I don't know if the following will help but here's what I did this  
> evening:

Thanks for your efforts. I won't be at the office for some days now, but  
just some comments that I can write right away.

> #1. Create a TSOAPAttachment-derived type:
>
>   TMySOAPAttachment = class(TSOAPAttachment)
>   public
>     function   ObjectToSOAP(RootNode, ParentNode: IXMLNode;
>                             const ObjConverter: IObjConverter;
>                             const Name, URI: InvString; ObjConvOpts:
> TObjectConvertOptions;
>                             out RefID: InvString): IXMLNode; override;
>     procedure  SOAPToObject(const RootNode, Node: IXMLNode; const
> ObjConverter: IObjConverter); override;
>   end;
>
>
> #2. In the initialization section of the unit, register the type:
>
>
> initialization
>   RemClassRegistry.RegisterXSClass(TMySOAPAttachment,  
> SBorlandTypeNamespace,
> 'TMySOAPAttachment', '', False, ocNoMultiRef);

I did not register my derived class. Could that cause the problem that I  
had seen? Maybe.

> #3. The relevant method in your case is ObjectToSOAP:
>
> 
>
> function TMySOAPAttachment.ObjectToSOAP(RootNode, ParentNode: IXMLNode;
>   const ObjConverter: IObjConverter; const Name, URI: InvString;
>   ObjConvOpts: TObjectConvertOptions; out RefID: InvString): IXMLNode;
> var
>   GUID: TGUID;
>   GUIDString: string;
> begin
>   CreateGuid(GUID);
>   GUIDString := GuidToString(GUID);
>   GUIDString := Copy(GuidString, 2, Length(GuidString) -2 );
>   ObjConverter.AddAttachment(Self, GuidString);
>   Result := nil;
> end;

Hm, so just returning nil would be clearly an error?


> You can tweak the ObjectToSOAP method if you don't want to use a GUID.

Aha, obviously, just returning nil in the above method is not an error? As  
mentioned in the other posting, I just returned nil and got the TMSDOMAttr  
exception (which applies to parsing or creating XML elements). But this  
might be connected to the fact that I did not register my class with the  
RemClassRegistry.

Thanks, I'll try this ASAP,

On Wed, 30 Jan 2008 21:52:51 +0100, Jean-Marie Babet <bbabet@borland.com> 

wrote:

> Hello,
>
> Not registering the class will clearly have some side-effects as by  
> default the SOAP runtime assumes TRemotable types are multiref'ed.

Hm, I could try your suggestions now. What I ended up with was a different  
DOM error:
ESOAPDomConvertError: Die Konvertierung von Klasse TXMLNodeList zu SOAP  
wird nicht unterstützt - SOAP-Klassen müssen von TRemotable abgeleitet  
worden sein

(roughly translated: conversion of class TXMLNodeList to SOAP is not  
supported - SOAP Classes must be derived from TRemotable).

I am at a loss. Do you have any other suggestions? I could try to create a  
minimal test case. Would you mind looking at that?

Hello,

Yes, I'm happy to take a look at a test case if you have one. The issue with
TXMLNodeList makes sense (I mean, we cannot serialize non-TRemotable
types)... except that you probably would never try to serialize a
TXMLNodeList directly?

Please let me know how I can help!

Cheers,

Bruneau.

Hello,

> Side question: In
>    TMySOAPAttachment.ObjectToSOAP
> you wrote
>    ObjConverter.AddAttachment(Self, GuidString);
>
> Is this attachment cleared, or do I have to do that myself? I realize that
> the object instance of TMySOAPAttachment is freed and thus should not be
> referenced by the framework again. But is this the proper way? Or should I
> somehow clear the attachment list of the Converter?

I'll need to look at the code to confirm but (to be consistent with the rest
of the framework), in 'Client' mode you're responsible for all cleanup:

#1 If you pass something as a Request parameter when calling a Service,
you're responsible for cleaning it up.
#2 If the framework returns a resource to you as a part of a response,
you're responsible for cleanup it up.

The importer generates code such that any container cleanups its fields in
its destructor. So if a TRemotable object contains other TRemotable objects
(or arrays of these), only the container needs to be cleaned up as its
destructor takes care of the inner objects.

So, my guess would be that you need to cleanup the attachment sent. I
typically run most test programs with FastMM as it points out things like
that really quickly.

If I find out otherwise, I'll post a follow-up msg.

Cheers,

Bruneau.

PS: The SOAP runtime performs a lot of automatic cleanup in server mode
because we fabricate resources from the XML requests (i.e. we own these
resources) and we take ownership of resources returned as response by the
service because control is never returned to the service for cleanup.