Sorry -- under CXF-445.
https://issues.apache.org/jira/browse/CXF-445
On Mar 5, 2007, at 7:38 AM, Glynn, Eoghan wrote:
Fred,
Where did you submit the patch to?
/Eoghan
-----Original Message-----
From: Fred Dushin [mailto:[EMAIL PROTECTED]
Sent: 05 March 2007 11:30
To: [email protected]
Subject: Re: Accessing Connection-based info from the transport
Thanks, Eoghan.
I can't really speak to the IP Address issue you raise --
right now what I'm really concerned about is TLS-related
information, which in the case of the Jetty implementation,
is available on off the SSLSession. The local and peer IP
addresses are available for the asking there, too, but
currently I have no need for them (though I'd certainly be
open to exposing this information to anyone downstream).
As for the aesthetic issue about whether it's easier to
design a new struct to carry this information, for each type
of information, I've submitted a patch which I think fairly
effectively avoids having to do this, and I'd argue it's no
less usable or readable on the part of the producer or
consumer of this information. You'll see patterns like
ContextInfo info = message.get(TLSSessionContract.class);
java.security.cert.Certificate[] peerCerts = info.get
(TLSSessionContract.PEER_CERTIFICATES);
and off you go. This is in contrast to something like:
TLSSessionInfo info = message.get(TLSSessionInfo.class);
java.security.cert.Certificate[] peerCerts =
info.getPeerCertificates();
but it has the advantage that it's slightly more future-proofed.
E.g., in the latter case, if TLSSessionInfo changes, then
implementations will fail to compile. And of course the type
(ContextInfo) has general applicability outside of my myopic
needs at present.
Of course, I'm not a committer here, so feel free to ignore
the patch. If this forum seriously feels the former approach
is a detriment to the project, I can easily retrofit the
approach, but I think that would be unfortunate. The former
approach is really a lot simpler and cleaner, IMO.
Please let me know ASAP.
Thanks,
-Fred
