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:[EMAIL PROTECTED] > Sent: 05 February 2007 15:17 > To: [email protected] > 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/% > [EMAIL PROTECTED] > > > > -----Original Message----- > > From: Lin, Bozhong [mailto:[EMAIL PROTECTED] > > Sent: 05 February 2007 14:37 > > To: [email protected]; [email protected] > > 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:[EMAIL PROTECTED] > > Sent: Wed 1/31/2007 2:27 AM > > To: [email protected] > > Subject: RE: Duplication in http2 module > > > > > > > > > -----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 > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > >
