Just to be clear, my +1 is a long-term strategy, and is not held with
the conviction of a religious belief. A patch for CXF-1849 has been
applied, and as long as I can get that back-merged to the 2.1.x-fixes
branch, that gets me over the hump.
-Fred
On Oct 9, 2008, at 5:41 PM, Fred Dushin
Yeah, I think this summarizes it well.
On Oct 9, 2008, at 5:10 PM, Sergey Beryozkin wrote:
Hi,
I'd like to try to summarize what we've talked at this thread. Fred
- please
feel free to challenge what I'm about to say :-)
Original problem : server-side outbound Policy interceptor assumes
Hi,
I'd like to try to summarize what we've talked at this thread. Fred - please
feel free to challenge what I'm about to say :-)
Original problem : server-side outbound Policy interceptor assumes that no
policy alternative has been asserted on the outbound path and reports a
failure by (mistaken
Hi Fred
I strat thinking this message gets a bit off-track :-) Few more comments.
That's fine, in that the AssertionBuilder can render a decision about what interceptors to add to the chain. But that won't
solve the bug I've identified.
As we've said many times what will solve this probl
On Oct 9, 2008, at 10:38 AM, Sergey Beryozkin wrote:
Does apply to the inbound our outbound path? Or both?
What are the semantics here?
This coarse-graned policy applies to an endpoint so as I said it's
up to the implementation as to whether it will affect in/
out/both pathes.
Tha
Hi
Suppose you have this config:
Does apply to the inbound our outbound path? Or both? What are the
semantics here?
This coarse-graned policy applies to an endpoint so as I said it's up to the implementation as to whether it will affect
in/out/both pathes. As far as the poli
Doh! That was supposed to be [{foo:Bar}, {bling}Blang]
On Oct 9, 2008, at 9:44 AM, Fred Dushin wrote:
And on the outbound side you'd get [{foo:Bar}, {gnu}Gnat]
On Oct 8, 2008, at 5:16 PM, Sergey Beryozkin wrote:
Hi
I agree with what Dan suggested - logging a message in a
PolicyVerificationOutInterceptor should suffice in most cases. Few
more
comments.
I think that asserting a policy on the outbound path makes sense
only if
a specification for a
o:[EMAIL PROTECTED]
Sent: 08 October 2008 18:02
To: [EMAIL PROTECTED]
Subject: More on server response policies
This is a continuation of the discussion at
http://mail-archives.apache.org/mod_mbox/cxf-dev/200808.mbox/%3c3AAFD5B7-693
[EMAIL PROTECTED]
I've confirmed that this is still a
That would probably get me over this particular hump, and it would be
the least disrptive, because I have cases where my clients are barfing
because they are getting an actual response, followed by a fault.
On Oct 8, 2008, at 1:38 PM, Daniel Kulp wrote:
That said, I think the PolicyVerificat
Fred,
Long message...Defintely would like to see what Sergey says. :-)
On Wednesday 08 October 2008, Fred Dushin wrote:
...snip
> C. The policy alternative selection algorithm (the
> AlternativeSelector) is different on the inbound request and outbound
> response side
This is a continuation of the discussion at
http://mail-archives.apache.org/mod_mbox/cxf-dev/200808.mbox/[EMAIL PROTECTED]
I've confirmed that this is still an issue in 2.2-SNAPSHOT, and I'd
like to start a discussion of solutions. I'll start by describing the
policy framework architecture,
12 matches
Mail list logo
