Hi Dan
On 01/08/13 22:51, Daniel Kulp wrote:
On Aug 1, 2013, at 4:58 PM, Sergey Beryozkin <[email protected]> wrote:
Hi Dan
On 31/07/13 23:42, Daniel Kulp wrote:
On Jul 30, 2013, at 12:07 PM, Sergey Beryozkin <[email protected]> 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.
Great stuff, thanks
Sergey
