cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guillaume Nodet" <gno...@gmail.com>
Subject Re: Duplication in http2 module
Date Thu, 08 Feb 2007 08:11:26 GMT
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 <ning.jiang@iona.com> 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: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
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>
> >>>>
> >>>
> >>>
> >
> >
> >
>
>


-- 
Cheers,
Guillaume Nodet
------------------------
Architect, LogicBlaze (http://www.logicblaze.com/)
Blog: http://gnodet.blogspot.com/

Mime
View raw message