On Aug 1, 2013, at 4:58 PM, Sergey Beryozkin <sberyoz...@gmail.com> wrote:
> Hi Dan > On 31/07/13 23:42, Daniel Kulp wrote: >> >> On Jul 30, 2013, at 12:07 PM, Sergey Beryozkin <sberyoz...@gmail.com> wrote: >> >>> I'd rather go and enable the direct dispatch style by default, will make >>> things a bit simpler for users (no need to know about >>> LocalConduit.DIRECT_DISPATCH unless really needed, and if they will need a >>> piped style then they'd disable it by setting LocalConduit.DIRECT_DISPATCH >>> to false) >> >> I'm OK flipping it, but I'd also want to try and actually fix the problem. >> Can you create a small test case and @Ignore it and point me at it? Then >> I can try and update the Local transport to actually work properly for that >> case. >> > As I mentioned on IRC, I made a GET test work in Pipe mode, for that to work > I needed to update the client runtime to add writer interceptors even for > cases when no output body is available and additionally write an empty string > into the OS. > > I'm not really sure I'd like to do it only for a LocalConduit to work in a > Pipe mode :-). May be a neater fix can be found. Have a look please when you > have a chance, see JAXRSLocalTransportTest#testProxyDirectDispatchGet and > comment out the line where a direct dispatch property is set. > > Enabling Direct Dispatch by default is not of high priority per se, but what > appeals to me there is that the same code which works in the production can > be parameterized on the address and reused with the local scheme, which is > quite cool - though of course it works for WS even with Pipe. > > Though I can imagine that at Spring/Blueprint level there could be multiple > jaxrs clients, some bound to HTTP, some to Local, etc - that can be done too > if Pipe by default is important for Local. Now fixed on trunk… I'll merge to the other branches tomorrow or later tonight. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
