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, 07 Feb 2007 16:36:22 GMT

Willem,

Can you give more detail on what your concerns were about the stability
or otherwise of Jetty 6 SSL support?

For example what specific features are considering buggy or entirely
missing?

Cheers,
Eoghan

> -----Original Message-----
> From: Glynn, Eoghan [mailto:eoghan.glynn@iona.com] 
> Sent: 05 February 2007 15:17
> To: cxf-dev@incubator.apache.org
> Subject: RE: Duplication in http2 module
> 
> 
> Well I think the original logic was that the Jetty6 SSL 
> support is in a pre-alpha state, so isn't suitable as a 
> straight replacement for Jetty5.
> Hence the motivation for maintaining support for both Jetty5 
> and 6 for a transition period.
> 
> BTW I'm not sure if the Jetty6 SSL really is still that 
> unstable ... at least the mortbay.org download page, the 6.1 
> version has the status "Stable" and mentions "Async SSL" in the notes.
>  
> So before we waste any cycles on figuring out how to allow 
> Jetty 5 & 6 peacefully co-exist, I think it would be worth 
> investing some effort in establishing definitively the 
> stability or otherwise of Jetty6 SSL.
> 
> Now if Jetty6 is still considered unstable, then we'd have to 
> come up with some (e.g. class-loading) cleverness to allow 
> selective loading of the Jetty 5 or 6 artefacts. Fortunately 
> the Jetty 5 and 6 APIs expose different classes to our code 
> (e.g. SslListener versus SslSelectChannelConnector), so that 
> should simply things at compile time at least.
> 
> If on the other hand, we were happy enough to drop support 
> for Jetty5, this would simplify matters. For one thing, it 
> would allow the HTTP code to be restructured to take more 
> advantage of the non-blocking aspects of
> Jetty6 (see my previous mail[1] for more detail).
> 
> However if we do drop Jetty5 support, before just replacing 
> the http module with http2, its important to do an audit to 
> ensure that all changes applied to the http module since the 
> advent of the duplicated
> http2 module have also been reflected in the latter. Having 
> to do this sort of thing is another downside of the whole 
> duplication approach.
> 
> Cheers,
> Eoghan
> 
> 
> [1]
> http://mail-archives.apache.org/mod_mbox/incubator-cxf-dev/200
> 612.mbox/%
> 3cFA1787F64A095C4090E76EBAF8B183E071FB38@owa-emea.iona.com%3e  
> 
> 
> > -----Original Message-----
> > From: Lin, Bozhong [mailto:Bozhong.Lin@iona.com]
> > Sent: 05 February 2007 14:37
> > To: cxf-dev@incubator.apache.org; cxf-dev@incubator.apache.org
> > Subject: RE: Duplication in http2 module
> > 
> > So I just want to follow up a question on this discussion. If we 
> > agreed to refactor code according to the discussion, what this will 
> > have impact on packaging? i.e., are we going to ship both 
> jetty5 and 
> > jetty 6? or by default we just ship
> > jetty5 and let user download jetty6 if they want jetty6 support?
> > 
> > Regards,
> > Bo
> > 
> > -----Original Message-----
> > From: Glynn, Eoghan [mailto:eoghan.glynn@iona.com]
> > Sent: Wed 1/31/2007 2:27 AM
> > To: cxf-dev@incubator.apache.org
> > Subject: RE: Duplication in http2 module
> >  
> >  
> > 
> > > -----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