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 14:22:35 GMT
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: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