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 Fri, 09 Feb 2007 14:31:02 GMT

Cool, this is just the detailed info we needed on the status of Jetty6.

So yep I agree we drop Jetty5, and ultimately start leveraging the
non-blocking aspects on Jetty6.

Cheers,
Eoghan

> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com] 
> Sent: 08 February 2007 22:52
> To: cxf-dev@incubator.apache.org
> Subject: Re: Duplication in http2 module
> 
> I just talked to Greg and he said they're going to remove the 
> beta label for the SSL support in 6.1.2. They have one open 
> bug in 6.1.1 where you can get stuck in a loop if the socket 
> is closed at the wrong time, but I believe
> 6.1.2 will be out before our next release so I'm not too 
> concerned about that.
> 
> Given this my vote would be that the http module starts using 
> the NIO & continuations bits so we can remove the one thread 
> per request limit.
> 
> - Dan
> 
> On 2/8/07, Glynn, Eoghan <eoghan.glynn@iona.com> wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Jiang, Ning [mailto:Ning.Jiang@iona.com]
> > > Sent: 08 February 2007 14:39
> > > To: cxf-dev@incubator.apache.org
> > > Subject: RE: Duplication in http2 module
> > >
> > > Hi,
> > >
> > > Jetty6 provides Continuation to leverage the NIO for better 
> > > supporting the scalable AJAX applications to be built with 
> > > threadless waiting for asynchronous events.
> >
> > Yep, Jetty Continuations were originally motivated by the traffic 
> > patterns typical encountered AJAX servers (where clients hog 
> > connections for extended period to do polling, but these 
> connections 
> > lie idle much of the time).
> >
> > But I don't think Continuations are limited to the AJAX use-case, 
> > rather this mechanism is quite general by the looks of 
> things (right, 
> > Guilluame?). For CXF, Continuations would allow us to suspend the 
> > thread servicing a request if the next incoming chunk wasn't 
> > immediately available, so as to allow that thread do some work on 
> > behalf of some other request. So we get to scale up to 
> handle larger 
> > numbers of simultaneous clients (each slowly writing large 
> chunked requests).
> >
> > > Current CXF http
> > > just server as request/response transport model. We 
> really take no 
> > > advantage of Jetty6 NIO support in CXF.
> > >
> > > I ran the performance test against http module which uses
> > > Jetty5 and http2 module which uses Jetty6.
> > >
> > > Here is some comparison between the average latency of
> > > cxf-transport-http2 (Jetty5 blocking Listener) and 
> > > cxf-transport-http (Jetty6 NIO-based SelectChannelConnector) with 
> > > different sizes of message on linux box.
> > >     Thread number __latency with Jetty6 __latency with Jetty5
> > > Cxf-T1 __1 __________22.022 ___________22.287
> > > Cxf-T3 __3 __________37.011 ___________36.770
> > > Cxf-T5 __5 __________42.860 ___________42.451 Cxf-T10 _10 
> > > _________39.230 ___________39.023
> > > Cxf-T15 _15 _________39.316 ___________38.573 Cxf-T30 _30
> > > _________39.669 ___________38.277 Cxf-T50 _50 _________39.348
> > > ___________39.315
> > >
> > > Because of our test model is that the client will not has 
> a rest but 
> > > just keeps on sending request after it get the response for the 
> > > server. You can see from the data that Http2 module's 
> performance is 
> > > not better than Http module.
> > >
> > > But I think we still need to move forward to Jetty6 :).
> > > Eoghan I agree to use Jetty6 {Ssl}SocketConnector to 
> replace Jetty5.
> >
> > Great.
> >
> > I think the neatest approach for now is to go with Jetty6, 
> but stick 
> > with the presumaly solid {Ssl}SocketConnector, and unify the Jetty6 
> > and Servlet code (see http://issues.apache.org/jira/browse/CXF-343).
> >
> > > BTW: It is easy to change our http engine to use the trandition 
> > > blocking IO or NIO by using different connector.
> >
> > Sure we can easily swap between the SelectChannelConnector and 
> > SocketConnector as things currently stand, but that's only because 
> > we're using the SelectChannelConnector as if it actually was a 
> > SocketConnector ... i.e. we're not taking any advantage of the 
> > non-blocking capabilities.
> >
> > Once we start leveraging the async capabilites of 
> > SelectChannelConnector, it wouldn't be so straight-forward to move 
> > back to the blocking model of the SocketConnector.
> >
> > Cheers,
> > Eoghan
> >
> > > Cheers,
> > >
> > > Willem.
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Glynn, Eoghan [mailto:eoghan.glynn@iona.com]
> > > Sent: 2/8/2007  20:06
> > > To: cxf-dev@incubator.apache.org
> > > Subject: RE: Duplication in http2 module
> > >
> > >
> > > Hi Guillaume ...
> > >
> > > > -----Original Message-----
> > > > From: Guillaume Nodet [mailto:gnodet@gmail.com]
> > > > Sent: 08 February 2007 08:11
> > > > To: cxf-dev@incubator.apache.org
> > > > Subject: Re: Duplication in http2 module
> > > >
> > > > 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).
> > >
> > > Agreed.
> > >
> > > In fact we're using the NIO-based SelectChannelConnector and 
> > > SslSelectChannelConnector in the http2 module without actually 
> > > taking any advantage of the non-blocking aspect of these 
> connectors 
> > > ... i.e. we don't use Continuations to allow a thread 
> that's blocked 
> > > while servicing one request (e.g.
> > > awaiting further incoming chunks) to do some work 
> servicing another 
> > > requests for which data is available.
> > >
> > > As far as I can see we're using the APIs that are potentially 
> > > capable of supporting an async model to just do 
> traditional blocking 
> > > I/O as we did for Jetty5 (correct me if I'm wrong here Willem).
> > >
> > > So it seems we're not really getting any benefit from the 
> > > {Ssl}SelectChannelConnector capabilities, but we're still 
> incurring 
> > > the ongoing cost of maintaining both the http &
> > > http2 modules.
> > >
> > > So I'd propose the following actions:
> > > 1. Switch http2 module to use the {Ssl}SocketConnector 
> APIs instead 
> > > of the {Ssl}SelectChannelConnectors 2. Audit duplicated 
> code in http 
> > > & http2 modules to ensure all changes applied to http have been 
> > > reflected in http2 3. Remove the http (Jetty5-based) 
> module, rename 
> > > http2 (Jetty6-based) to http, and update all poms etc. to 
> depend on 
> > > Jetty6 4. If and when the SslSelectChannelConnector 
> matures in the 
> > > eyes of the Jetty folks (i.e. the BETA log warning goes away), we 
> > > then switch back to the {Ssl}SelectChannelConnector APIs, 
> but this 
> > > time we actually leverage the async I/O to increase throughput in 
> > > heavily loaded scenarios.
> > >
> > > Thoughts anyone?
> > >
> > > Cheers,
> > > Eoghan
> > >
> > >
> > > > 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/
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> 
> 
> 
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
> 

Mime
View raw message