cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <...@envoisolutions.com>
Subject Re: Duplication in http2 module
Date Thu, 08 Feb 2007 22:52:18 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message