Even if the SslSelectChannelConnector is considered unstable, there is the SslSocketConnector which is stable. This would means that ssl would not use nio, but that's not a big deal compared to embed two different versions of jetty (and anyway, jetty5 does not support nio either).
On 2/8/07, Willem Jiang <[EMAIL PROTECTED]> wrote:
Hi Eoghan, I found the log message "The SslSelectChannelConnector is a BETA quality release." when I played with the Jetty 6.1.1 SSLSelectChannelConnector in http2 moduel. So I get the conclustion that Jetty6 SSL support is not stable. I am not SSL experct, I can't tell exacly what specific features are unstable or missing. I just asked the Jetty guy for they help to know the status of the Jetty 6 SSL support. I hope I can get the answer soon. Willem. Glynn, Eoghan wrote: >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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>> >>>> >>> >>> > > >
-- Cheers, Guillaume Nodet ------------------------ Architect, LogicBlaze (http://www.logicblaze.com/) Blog: http://gnodet.blogspot.com/
