Hi Raymond, Sebastien, Sorry I dropped off of the discussion for awhile. I took a look at the r628163 code.
Let me see if I'm understanding this correctly: When an Invoker implements PassByValueAware.allowsPassByReference() and returns 'true', it means exactly this: "I know that, on this chain, the PBVInterceptor won't need to do a copy". So a binding invoker might set this on the chain knowing that the binding has done a copy, or the JavaImpl invoker (if the @AllowsPBR is detected on the Java impl), or the DataTransformationInterceptor might, assuming that if this interceptor is set up on the wire, then a copy must always be done. I had a hard time grasping this at first, I think because the name threw me off, until I started thinking of it in terms of: "noCopyByPBVInterceptorNeededOnThisChain()". Did I get this right? Assuming I did, it looks like a nice improvement. That said, I was actually using the DTInterceptor in a binding impl in a way such that it was NOT always doing a copy. It was a bit forced as I was converting to a holder databinding (but saving the original obj refs) to deal with the fact that I didn't know until I was in the binding whether I wanted to go remote (and copy the data at that point) or go a locally-optimized route (and possibly NOT copy the data). So this gets back to the discussion of how to selectively use the mediator from the binding impl rather than relying so much on the DTInterceptor always on the wire (which is all I'd thought to do in the past), which is more where I started in this thread. But, leaving the details of that aside for now, with this new support I'd certainly have the ability to say yes/no whether a copy had been done in my remote/local paths for my binding, from my binding invoker. I still wonder whether it's a good or bad assumption to assume the DTInterceptor always does a copy, since I found a use for it when it did not (but again that was a more ugly use). Scott On Feb 15, 2008 4:18 PM, Raymond Feng <[EMAIL PROTECTED]> wrote: > Hi, > > I just checked in the first cut under r628163: > http://svn.apache.org/viewvc?rev=628163&view=rev. The key changes are: > > 1) Add an optional PassByValueAware SPI > 2) Have invokers for reference bindings and implementations to implement > this SPI to express their capability to support pass-by-reference > 3) Make the PassByValueInterceptor honor the allowsPassByReference by > invokers > > I haven't refactored the PassByValueInterceptor into a utility yet. Ideally, > the client side of the invocation chain should decide if it needs to call > the PassByValueUtil to copy the data before it dispatches to the invocation > chain. The client can be the JDKInvocationHandler (proxy), the reference > binding dispatcher or the service binding listener. This is the next TODO. > Please feel free to jump in if you're interested. > > Thanks, > Raymond > > ----- Original Message ----- > From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]> > To: <[email protected]> > Sent: Friday, February 08, 2008 3:51 PM > Subject: Re: Bypassing unnecessary transforms by Tuscany databinding > framework > > > > > Raymond Feng wrote: > >> +1 on the proposal. > >> > >> The interceptor could just return the flag based on its capability > >> without asking the next one. And the runtime can query it from the head > >> in the invocation chain and stop when it gets a true. > >> > > > > It could, but that would be making an assumption on the behavior of the > > interceptor - assuming that it always calls next.invoke(message). > > > > Here's an example showing that: > > > > Message invoke(Message message) { > > // example implementation > > if (someCondition) { > > return next.invoke(message); > > } else { > > // do something else > > return message; > > } > > } > > > > Imagining that the next interceptor always returns false, hardwired > > invocation chain walking logic will return false (incorrect) instead of > > true. > > > > Without hardwired logic in the core runtime, the interceptor can simply > > implement allowsPassByReference() like this: > > > > boolean allowsPassByReference() { > > // example implementation > > if (someCondition) { > > return next.allowsPassByReference(); > > } else { > > return true; > > } > > } > > > > and return the correct value. > > > > In general, I think that more control and hardwired rules in the core > > runtime (leaving less flexibility to the extensions) eventually cause > > further complications... when the hardwired rules get in the way and we > > then have to pile yet another mechanism or rule on top to work around them > > :) > > -- > > Jean-Sebastien > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
