Speaking from the field, you do not want to drop 1.5. There are organization
out there that are not moving to 1.6 (or are moving very slowly) out of fear of
Oracle's collecting royalties under the 1.6 redistribution terms.
CXF is meant to be an embedded library. If you drop support for 1.5, yo
-0 (advisory and non-binding)
I'd really like to see a change to the tlsClientParameters, to replace
the disableCNCheck flag with a reference to a HostnameVerifier. But
it can wait for 2.1.1.
-Fred
PS> Congratulations to the entire CXF team on graduation!
On Thu, Apr 24, 2008 at 3:29 AM
Absolutely. The config is designed to reflect the JSSE APIs as much
as possible, so anything we can do to improve that, the better.
-Fred
On Apr 24, 2008, at 5:09 PM, Daniel Kulp wrote:
Certainly may be easier to configure
some security stuff if they user is very familliar with JSSE and th
Is there a reason hashed collections are used, almost exclusively, in
CXF? Even in cases where collections are predictably small, Hash(Maps|
Sets) almost always win out over their sortable cousins in the
java.util namespace, and this, even when the keys are sortable.
Is there a technical re
Performance measurements would certainly be in order, if a change were
to occur.
What I'm more concerned about is flushing out any ordering assumptions
in collections that are inherently unordered. That, and
reproducibility of errors on Mac/Windows/Linux/etc
On Apr 29, 2008, at 10:26 AM,
+1
Ideally, we also need some custom spring beans and/or an API to hide
all the WSS4J-isms in client code, because (IMO) it's really
inappropriate to expose WSS4J, as a WS-Security provider at this
level. (And I say this as a WSS4J committer). WS-SecurityPolicy
would be an appropriate c
I've done some experimentation in this area.
I can say that the WS-SecurityPolicy schema compiles without any
problems in CXF, for a start. There may be issues with duplicated
types that are generated, which you might be able to circumvent with
the JAXB compiler, but I haven't looked into
I think the right place for nonce support is in WSS4J, itself, though
honestly, a lot of work needs to be done to WSS4J to get it "up to
snuff" with CXF. (Java5, JaxB support, maven, etc etc)
I'd like to get a sense of what people need, in terms of WS-
SecureConversation and WS-Trust suppor
Hi Glen,
Thanks for the comments. Some responses in-line, though these are
more ramblings, than anything else. Please excuse any straw-man
arguments I make, as you may have already considered a lot of this.
On Jun 20, 2008, at 5:05 PM, Glen Mazza wrote:
As for WS-SecureConversation, AFA
I'm having trouble with the CXF policy framework, which is causing a
little bit of grief. I think this is a developer, as opposed to a
user issue, as I /think/ it points to a bug in the policy framework.
If not, I can migrate the conversation to the users list.
What I'm finding is that
outgoing chains. Thus, the policy should
be able to
handle both sides of that.
Dan
On Thursday 07 August 2008 3:25:31 pm Fred Dushin wrote:
I'm having trouble with the CXF policy framework, which is causing a
little bit of grief. I think this is a developer, as opposed to a
user issue,
+1, FWIW
On Aug 14, 2008, at 9:51 AM, Daniel Kulp wrote:
I'm going to create the 2.1.x fixes branch probably tomorrow
morning. I'm
going to be digging into the ws-security policy stuff which I'm sure
is going
to be de-stabilizing things on trunk a bit. Thus, I think it's time
to
crea
Glen I think it's going to depend a lot on how your nodes are
architected. For example, if your intermediate is not co-located with
your target, but it needs access to the encrypted payload for any
reason (for example, just to make it far enough through the CXF
interceptor chain), then you
You need a secure means of exchanging keys. In general email is not a
trustworthy mechanism, as it is clearly tamperable. A phone call is
marginally better. Though given the current news about skype, I'd
think twice about that, too ;)
Of course, you might even say face-to-face is not sec
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,
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
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
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 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
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
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
21 matches
Mail list logo
