Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-dev@incubator.apache.org
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <7b774c950702090822j5efb48bdke8ac17ea47f7ce6e@mail.gmail.com>
Date: Fri, 9 Feb 2007 11:22:13 -0500
From: "Dan Diephouse" <dan@envoisolutions.com>
To: cxf-dev@incubator.apache.org
Subject: Re: Duplication in http2 module
In-Reply-To: <FA1787F64A095C4090E76EBAF8B183E071FBF2@owa-emea.iona.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_34358_7200244.1171038133392"
References: <FA1787F64A095C4090E76EBAF8B183E071FBF2@owa-emea.iona.com>

------=_Part_34358_7200244.1171038133392
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Great! Just an FYI, I don't think I ported the configuration changes I did
to the HTTP2 module. So if someone already started tackling this, you might
want to move over the Spring NamespaceHandlers and what not.

- Dan

On 2/9/07, Glynn, Eoghan <eoghan.glynn@iona.com> wrote:
>
>
> 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
> >
>


-- 
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

------=_Part_34358_7200244.1171038133392--