cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fred Dushin <>
Subject Re: Accessing Connection-based info from the transport
Date Mon, 12 Mar 2007 14:15:41 GMT

On Mar 12, 2007, at 9:55 AM, Glynn, Eoghan wrote:

> So I've taken the liberty of modifying your latest patch, to move all
> the various flavours of getTLSSessionInfo() logic to static methods on
> the org.apache.cxf.transport.https.SSLUtils class. The Destination  
> impls
> then all just need a single call out to a new
> SSLUtils.propogateSecureSession() method.

Perfect -- I should have just done something like that, too, if  
containment was the objective.  Sorry for forcing you to do this.

> I'm going to go ahead with the commit, but I did notice that you  
> updated
> the JettyHTTPDestinationTest in http2 but not http. Was this  
> deliberate,
> i.e. have you further test additions in the pipeline?

I don't have anything in the pipeline, no, but I could, if you think  
it would be a good idea.  The problem I was having was that the http  
test is not using EasyMock to create a mock http request -- it's  
creating an instance of an org.mortbak.http.HttpRequest, and using  
that instance for testing.  There is an oblique reference in a  
comment in the test to a limitation in EasyMock, such that it was  
unable to handle creation of an HttpRequest, but I didn't have time  
to track down the real limitation.

The http2 test, on the other hand, seems to have no such difficulty,  
presumably because something has changed in the Jetty interfaces, or  
the test implementor figured out how to drive EasyMock, or both.   
(Good that my changes actually caused the http2 tests to fail, which  
forced me into the test code)  That was part of the reason I asked  
about the half-life of the http module -- if it's living on marked  
time, it may not be worth the effort to fix its tests.

> BTW you're preaching to the converted on the issue of the duplication
> across http and http2.

Oh I know that :)  I've read your posts on this forum.

> In any case, we do have a long-term plan to sort this out: drop  
> support
> for Jetty5, move http2 to http, start taking advantage of the
> non-blocking APIs in Jetty6, and consolidate the duplication across  
> the
> Jetty- and servlet-based Destinations.

I guess if we could do this sooner rather than later, then we'd all  
benefit.  Hard to justify, I understand, when weighed against  
tangible featuredom, but more important, IMO, if not making the fix  
increases drag on productivity.


View raw message