cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <eoghan.gl...@iona.com>
Subject RE: Accessing Connection-based info from the transport
Date Mon, 05 Mar 2007 12:38:20 GMT

Fred,

Where did you submit the patch to?

/Eoghan 

> -----Original Message-----
> From: Fred Dushin [mailto:fred@dushin.net] 
> Sent: 05 March 2007 11:30
> To: cxf-dev@incubator.apache.org
> 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
> 

Mime
View raw message