cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <eoghan.gl...@iona.com>
Subject RE: Duplication in http2 module
Date Wed, 31 Jan 2007 07:27:13 GMT
 

> -----Original Message-----
> From: Jiang, Ning [mailto:Ning.Jiang@iona.com] 
> Sent: 31 January 2007 02:01
> To: cxf-dev@incubator.apache.org
> 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:eoghan.glynn@iona.com]
> Sent: Tue 1/30/2007 23:03
> To: cxf-dev@incubator.apache.org
> Subject: RE: Duplication in http2 module
>  
> 
> 
> 
> >-----Original Message-----
> >From: Willem Jiang [mailto:ning.jiang@iona.com]
> >Sent: Tue 1/30/2007 4:00 AM
> >To: cxf-dev@incubator.apache.org
> >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: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/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: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
> > > >
> > > >   
> > > >>
> >
> 
> 

Mime
View raw message