> -----Original Message----- > From: Jiang, Ning [mailto:[EMAIL PROTECTED] > Sent: 31 January 2007 02:01 > To: [email protected] > Subject: RE: Duplication in http2 module > > > Hi Eoghan, > > Thank you for your reply. > > You suggested to put the http2 into another branch which will > not effect the main line. It is easy to do in ClearCase. But > in svn, the branch is just a static copy from the mainline. > My question is if I put the http2 into a branch, when the > mainline transport code had be changed, how can I sync these > mainline's changes to the branch?
Well the synching up would be a manual process, as it is now with http2 on the mainline but completely separate from the main http module. > Now we are working on pull the common transport logic to the > abstract Destination and Conduit. So there is another option, > we just move the Jetty6 support code into the http module , > then we can get ride of http2 module. Sure, that would be the preferred option, and basically I was originally advocating such a merge into a single http module (as long as the duplication is also properly addressed). The idea would be factor out the common logic into abstract base classes, and then provide pluggable API-specific components for Jetty5, Jetty6, and Servlet. But IIRC you didn't want to do this refactoring as the Jetty6 stuff was still pre-alpha and hence not suitable use in the main http module. So the option to move to a branch was a second choice alternative. Cheers, Eoghan > Cheers, > > Willem. > > -----Original Message----- > From: Glynn, Eoghan [mailto:[EMAIL PROTECTED] > Sent: Tue 1/30/2007 23:03 > To: [email protected] > Subject: RE: Duplication in http2 module > > > > > >-----Original Message----- > >From: Willem Jiang [mailto:[EMAIL PROTECTED] > >Sent: Tue 1/30/2007 4:00 AM > >To: [email protected] > >Subject: Duplication in http2 module > > > >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. > > Yes, the whole point is that much of the logic in the > servlet, Jetty5- and Jetty6-based HTTP transports is actually > common to all three and hence is sharable via abstract base classes. > > I'd already raised a JIRA issue > (http://issues.apache.org/jira/browse/CXF-343) to remove the > duplication from the servlet transport. A similar unification > approach could also be used for the Jetty5 and Jetty6-based > HTTP transports. > > >2. If we want to support Jetty5 and Jetty6 in the same http > transport > >module, how can we achieve it. > > Simply by encapsulating all usage of Jetty-version-specific > APIs into pluggable components. > > >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. > > Sure the APIs are slightly different, but that doesn't > prevent sharing all the code that actually is common. > > Now the refactoring job is made easier by the fact that the > logic common to *all* Destination implementations (i.e. both > HTTP and non-HTTP) is now factored out into an > AbstractDestination class. However, there's still plenty of > duplicated and potentially sharable logic in the three HTTP > Destination implementations, e.g. the logic concerned with > managing HTTP headers, acting on policies and setting message > properties. > > >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 ? > > I don't understand what exactly you're asking for help with. > Can you elaborate? > > Cheers, > Eoghan > > > > >Cheers, > > > >Willem. > > > >-----Original Message----- > >From: Glynn, Eoghan [mailto:[EMAIL PROTECTED] > >Sent: Mon 1/29/2007 18:13 > >To: [email protected] > >Subject: Duplication in http2 module [was RE: svn commit: r497869 - > >/incubator/cxf/trunk/rt/transports/http2/src/main/java/org/ap > ache/cxf/t > ransport/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:[EMAIL PROTECTED] > > > Sent: 19 January 2007 18:08 > > > To: [email protected] > > > 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 > > > > > > > > > > > >> > > > >
