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.
-Fred
