Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: domain of eoghan.glynn@iona.com
 designates 62.221.12.33 as permitted sender)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Duplication in http2 module
Date: Wed, 7 Feb 2007 16:36:22 -0000
Message-ID: <FA1787F64A095C4090E76EBAF8B183E071FBE1@owa-emea.iona.com>
Thread-Topic: Duplication in http2 module
Thread-Index: 
 AcdEI1F2EzTyLMHITHGkw6DCIcsWTgAXH3QAABYUA7EAC9ypsAEK33WxAABKaFAAaHWu0A==
From: "Glynn, Eoghan" <eoghan.glynn@iona.com>
To: <cxf-dev@incubator.apache.org>


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]=20
> Sent: 05 February 2007 15:17
> To: cxf-dev@incubator.apache.org
> Subject: RE: Duplication in http2 module
>=20
>=20
> Well I think the original logic was that the Jetty6 SSL=20
> support is in a pre-alpha state, so isn't suitable as a=20
> straight replacement for Jetty5.
> Hence the motivation for maintaining support for both Jetty5=20
> and 6 for a transition period.
>=20
> BTW I'm not sure if the Jetty6 SSL really is still that=20
> unstable ... at least the mortbay.org download page, the 6.1=20
> version has the status "Stable" and mentions "Async SSL" in the notes.
> =20
> So before we waste any cycles on figuring out how to allow=20
> Jetty 5 & 6 peacefully co-exist, I think it would be worth=20
> investing some effort in establishing definitively the=20
> stability or otherwise of Jetty6 SSL.
>=20
> Now if Jetty6 is still considered unstable, then we'd have to=20
> come up with some (e.g. class-loading) cleverness to allow=20
> selective loading of the Jetty 5 or 6 artefacts. Fortunately=20
> the Jetty 5 and 6 APIs expose different classes to our code=20
> (e.g. SslListener versus SslSelectChannelConnector), so that=20
> should simply things at compile time at least.
>=20
> If on the other hand, we were happy enough to drop support=20
> for Jetty5, this would simplify matters. For one thing, it=20
> would allow the HTTP code to be restructured to take more=20
> advantage of the non-blocking aspects of
> Jetty6 (see my previous mail[1] for more detail).
>=20
> However if we do drop Jetty5 support, before just replacing=20
> the http module with http2, its important to do an audit to=20
> ensure that all changes applied to the http module since the=20
> advent of the duplicated
> http2 module have also been reflected in the latter. Having=20
> to do this sort of thing is another downside of the whole=20
> duplication approach.
>=20
> Cheers,
> Eoghan
>=20
>=20
> [1]
> http://mail-archives.apache.org/mod_mbox/incubator-cxf-dev/200
> 612.mbox/%
> 3cFA1787F64A095C4090E76EBAF8B183E071FB38@owa-emea.iona.com%3e =20
>=20
>=20
> > -----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
> >=20
> > So I just want to follow up a question on this discussion. If we=20
> > agreed to refactor code according to the discussion, what this will=20
> > have impact on packaging? i.e., are we going to ship both=20
> jetty5 and=20
> > jetty 6? or by default we just ship
> > jetty5 and let user download jetty6 if they want jetty6 support?
> >=20
> > Regards,
> > Bo
> >=20
> > -----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
> > =20
> > =20
> >=20
> > > -----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
> > >=20
> > >=20
> > > Hi Eoghan,
> > >=20
> > > Thank you for your reply.=20
> > >=20
> > > You suggested to put the http2 into another branch which will not=20
> > > effect the main line. It is easy to do in ClearCase. But
> > > in svn, the branch is just a static copy from the mainline.  =20
> > > My question is if I put the http2 into a branch, when the=20
> mainline=20
> > > transport code had be changed, how can I sync these
> > mainline's changes
> > > to the branch?
> >=20
> > Well the synching up would be a manual process, as it is now with=20
> > http2 on the mainline but completely separate from the main http=20
> > module.
> >=20
> > > 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.
> >=20
> > Sure, that would be the preferred option, and basically I was=20
> > originally advocating such a merge into a single http=20
> module (as long=20
> > as the duplication is also properly addressed).
> >=20
> > The idea would be factor out the common logic into abstract base=20
> > classes, and then provide pluggable API-specific components for=20
> > Jetty5, Jetty6, and Servlet.
> >=20
> > But IIRC you didn't want to do this refactoring as the Jetty6 stuff=20
> > was still pre-alpha and hence not suitable use in the main http=20
> > module. So the option to move to a branch was a second choice=20
> > alternative.
> >=20
> > Cheers,
> > Eoghan
> >=20
> > > Cheers,
> > >=20
> > > Willem.
> > >=20
> > > -----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
> > > =20
> > >=20
> > >=20
> > >=20
> > > >-----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
> > > >=20
> > > >Hi Eoghan,
> > > >
> > > >The original thought to add the module http2 was we can=20
> 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=20
> 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=20
> > > >standalone web services.
> > >=20
> > > 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.
> > >=20
> > > I'd already raised a JIRA issue
> > > (http://issues.apache.org/jira/browse/CXF-343) to remove the=20
> > > duplication from the servlet transport. A similar
> > unification approach
> > > could also be used for the Jetty5 and Jetty6-based HTTP=20
> transports.
> > >=20
> > > >2. If we want to support Jetty5 and Jetty6 in the same http
> > > transport
> > > >module, how can we achieve it.
> > >=20
> > > Simply by encapsulating all usage of Jetty-version-specific
> > APIs into
> > > pluggable components.
> > >=20
> > > >In Jetty <=3D5, there was an API for pure Jetty HTTP requests and =

> > > >responses. The Jetty requests and responses where wrapped by the=20
> > > >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.
> > >=20
> > > Sure the APIs are slightly different, but that doesn't
> > prevent sharing
> > > all the code that actually is common.
> > >=20
> > > Now the refactoring job is made easier by the fact that the logic=20
> > > common to *all* Destination implementations (i.e. both HTTP and
> > > non-HTTP) is now factored out into an AbstractDestination class.=20
> > > However, there's still plenty of duplicated and potentially
> > sharable
> > > logic in the three HTTP Destination implementations,  e.g.=20
> > the logic
> > > concerned with managing HTTP headers, acting on policies
> > and setting
> > > message properties.
> > >=20
> > > >May be we need different Jetty factory to create the detail=20
> > > >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 ?
> > >=20
> > > I don't understand what exactly you're asking for help with.=20
> > > Can you elaborate?
> > >=20
> > > Cheers,
> > > Eoghan
> > >=20
> > > >
> > > >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:=20
> > r497869 -
> > > >/incubator/cxf/trunk/rt/transports/http2/src/main/java/org/ap
> > > ache/cxf/t
> > > ransport/http/JettyHTTPDestination.java]
> > > >=20
> > > >
> > > >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=20
> transport or=20
> > > >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 -=20
> > > > > /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=20
> want the=20
> > > > > 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=20
> > > > > > duplication-heavy servlet code:
> > > > > > http://issues.apache.org/jira/browse/CXF-343
> > > > > >
> > > > > > Cheers,
> > > > > > Eoghan
> > > > > >
> > > > > >  =20
> > > > > >>
> > > >
> > >=20
> > >=20
> >=20
> >=20
>=20