cxf-dev mailing list archives

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


Where did you submit the patch to?


> -----Original Message-----
> From: Fred Dushin [] 
> Sent: 05 March 2007 11:30
> To:
> 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);
>[] peerCerts = info.get 
> and off you go.  This is in contrast to something like:
> TLSSessionInfo info = message.get(TLSSessionInfo.class);
>[] 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

View raw message