The problem with the flag is that that implementing that also isn't without issues, especially at this late stage in our release cycle, so i've been looking for a simpler way that solves most cases. Comments inline...
...ant On 9/10/07, Scott Kurz <[EMAIL PROTECTED]> wrote: > > Apologies for opening TUSCANY-1678 without noticing the earlier JIRA or > this > discussion. > > > On 9/7/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > > > > > I didn't quite get Raymond's comment that we'll have to pass a flag in a > > message header. Don't we know what to do w.r.t pass by value just by > > looking at the source and target interfaces? Can't we just decide to > > either insert the interceptor in the invocation chain or not when the > > invocation chain is built? > > > > One problem with deciding when the invocation chain is built is supporting > the case where a service-side binding > impl accepts requests from either local or remote-JVM clients (the 2nd > case > in TUSCANY-1678). The local client may > require a copy while not the remote one. Not sure exactly what to do about that case yet, but it does seem like those are two separate paths through the binding and so it should be possible to set some flag somewhere at build time not just at invocation time. Maybe by cloning the Interface and flipping the isRemotable flag to trick the copy code or something like that, i'll have a play around to see if i can find something but say if you've any ideas. Also are we sure the presence of a DataTransformationInteceptor on the chain > means a copy has been done? Is that > part of the SPI contract? Say you had a databinding which transformed > Java complex types from one system to another but > did nothing with a simple java.lang.Integer. Is it established that the > databinding impl should do a copy in that case? How about adding a method to the data binding interface to say whether or not the transformation it does results in a copy occurring? ...ant
