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 >
