You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by "Lin, Bozhong" <Bo...@iona.com> on 2007/02/05 15:36:46 UTC
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
> > > >
> > > >
> > > >>
> >
>
>
RE: Duplication in http2 module
Posted by "Jiang, Ning" <Ni...@iona.com>.
Hi Bo,
we suppose that the http transport should have some intelligence, it can load different http engine support by look up it classpath. If the classpath has the Jetty5, it will load the Jetty5 support http engine. Jetty5 and Jetty6 can not be load by the same classloader. By default we can only add Jetty5 in the package.
If user want to use Jetty6, he need remove the Jetty5 from the class path and put Jetty6 in to class path. Maybe we need some shell script to help people to change the manifest jar.
Any thoughts?
Willem.
-----Original Message-----
From: Lin, Bozhong [mailto:Bozhong.Lin@iona.com]
Sent: Mon 2/5/2007 22:36
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
> > > >
> > > >
> > > >>
> >
>
>