Ant,

ant elder wrote:
I'm looking at what we could do for TUSCANY-1559 which is about unnecessary
pass-by-value copies causing failures when arguments aren't serializable.
The problem is on line 260 of JavaComponentContextProvider where it tries to
determine if the pass-by-value invoker is required, but it doesn't take into
account whats at the other end of the invocation chain.

I'm a bit confused by this. These statements seem to imply that you can't use the service/reference in the case where remoting is going on. That will indeed be the case if you have non-serializable arguments.

But why is the invocation chain of any relevance here? Or have I got the wrong end of the stick.

Any service or reference that is remotable must have an interface that can be serialized onto a wire. SCA expresses this in terms of mappability to WSDL. If it's remotable it must be expressible in WSDL and serialization is part of this picture.


How about changing this so its not the Java implementation types
responsibility to handle pass-by-value and move it out into core, having a
separate RuntimeWireProcessor and Interceptor for pass-by-value support, and
don't do copies if the source and target interfaces use different
databindings?

   ...ant

Different databindings surely is not part of the problem. Again, you can map into and out of a "canonical" form (XML) if required - that is where the WSDL mappability comes in.

Where there IS an opportunity for avoiding serialization is for remotable interfaces which are marked "AllowsPassByReference" - then, if the target happens to be local you can use pass by ref and avoid any serialization. Optimization of this kind will require some smarts in the invocation chain - but it is all clearly marked in terms of the SCDL.

But I fail to see how failures can occur for "unnecessary pass-by-value" copies in any circumstance other than one that SHOULD be an error.


Or am I missing something here?


Yours,  Mike.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to