Duplication in http2 module

[Willem Jiang <ni...@iona.com>]

Hi Eoghan,

The original thought to add the module http2 was we can replace the 
Jetty5 with new NIO support Jetty6, than we  can replace http  module 
with http.
Unfortunately when I finished the porting , I found the Jetty6 ssl stuff 
is still in a pre-alpha state. So I can move http2 to http.

There are some my random thoughts about the http2 module.

1.  making the http transport decouple with the detail Http Transport 
engines.
In this way ,we can share the common http transport logical code with 
the different Http Transport engines.
So the CXF can support tomcat , Jetty5 , Jetty6 to provide the 
standalone web services.

2. If we want to support Jetty5 and Jetty6 in the same http transport 
module, how can we achieve it.
In Jetty <=5, there was an API for pure Jetty HTTP requests and 
responses. The Jetty requests and responses where wrapped by the 
ServletHandler to provide the Servlet API for requests and responses.
In Jetty 6, all requests and responses are based on the Servlet APIs 
requests and responses.
May be we need different Jetty factory to create the detail 
JettyHTTPServerEngine and JettyHTTPDestionation which will consume the 
different version's Jetty API.

These will take some time to finish and we also need to wait for the 
Jetty6 SSL engine stable release. Eoghan, I agree we can put the http2 
into the branch which will not take effect with the mail line.
But I have no ideal how to sync the branch with the main line's http 
transport common logical. Can someone help me out ?

Cheers,

Willem.

-----Original Message-----
From: Glynn, Eoghan [mailto:eoghan.glynn@iona.com]
Sent: Mon 1/29/2007 18:13
To: cxf-dev@incubator.apache.org
Subject: Duplication in http2 module [was RE: svn commit: r497869 - 
/incubator/cxf/trunk/rt/transports/http2/src/main/java/org/apache/cxf/transport/http/JettyHTTPDestination.java]
 

Willem,

The problem with keeping these modules separate is that every change to
the main http module has to be duplicated manually to the http2 module
which is time-consuming and error-prone.

So if the http2 stuff is still in a pre-alpha state, then it should be
taken off the mainline onto a branch until its ready to either share
common base classes with the core (Jetty5-based) http transport or
replace it outright.

Cheers,
Eoghan

 > -----Original Message-----
 > From: Willem Jiang [mailto:ning.jiang@iona.com]
 > Sent: 19 January 2007 18:08
 > To: cxf-dev@incubator.apache.org
 > Subject: Re: svn commit: r497869 -
 > /incubator/cxf/trunk/rt/transports/http2/src/main/java/org/apa
 > che/cxf/transport/http/JettyHTTPDestination.java
 >
 > Hi Eoghan,
 >
 > The duplication in http transports is because I don't want
 > the development of the Jetty6 support takes effect to the
 > current code base.
 >
 > Since Jetty6 's ssl support is in pre-alpha state , we don't
 > want to replace Jetty5 with Jetty6 right now, I agree we can
 > move the Jetty6 supporting from rt-tranpsorts-http2 to
 > rt-transports-http to reduce the duplication, and get CXF
 > http-transport more flexible.
 >
 > Cheers,
 >
 > Willem.
 >
 > Glynn, Eoghan wrote:
 > > Hi Willem,
 > >
 > > Why all the duplication in rt-transports-http2?
 > >
 > > If we're going to keep the Jetty5-based rt-transports-http
 > stuff, then
 > > the two modules should be merged so as to avoid duplication, with
 > > common code factored up into abstract base classes.
 > >
 > > I've raised an JIRA task for a similar refactoring of the
 > > duplication-heavy servlet code:
 > > http://issues.apache.org/jira/browse/CXF-343
 > >
 > > Cheers,
 > > Eoghan
 > >
 > >   
 > >>