cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fred Dushin <f...@dushin.net>
Subject Re: Accessing Connection-based info from the transport
Date Mon, 05 Mar 2007 11:30:26 GMT
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

Mime
View raw message