Tomcat 7 is a Servlet 3.0 implementation with requirements to support Java 6, wouldn't this break that contract if we do it for NIO/BIO? Could this be done as a extras package for the Java connectors? Why not add this into trunk first, and work with it there, as opposed to an external repository? Filip
----- Original Message ----- > From: "Costin Manolache" <cos...@gmail.com> > To: "Tomcat Developers List" <dev@tomcat.apache.org> > Sent: Saturday, March 24, 2012 10:44:19 PM > Subject: Re: SPDY support > > Hi, > > I did a first round of backporting to tomcat7 - only the hooks. > Please take > a look and let me know: > > https://github.com/costinm/tomcat/blob/trunk/tomcat7.diff > > I've also submitted to git the changes to support SPDY/NPN for NIO > and JIO > connectors - almost same diff, but the important change is: > > https://github.com/costinm/tomcat/commit/698f4105a818e872877f3e8d9c50e003e2e706f0 > > The problem is that it add a compile dep on > http://wiki.eclipse.org/Jetty/Feature/NPN > > the classes are modified from openjdk7 - it'll also need to be added > at > runtime ( if spdy support with nio/jio is needed ), but I assume > users can > download the jar until it gets merged into jdk7. > > Alternative is to move all the coyote/spdy/{nio,jio} classes to a > separate > repository, outside tomcat tree. I guess we could also move all spdy > impl > to a separate repo and only leave the hooks. > > Costin > > On Mon, Mar 19, 2012 at 11:31 AM, Costin Manolache <cos...@gmail.com> > wrote: > > > > > > > On Mon, Mar 19, 2012 at 10:43 AM, Gus Heck <ph...@copyright.com> > > wrote: > > > >> I just bumped into the whole concept of SPDY this morning, and it > >> sounds > >> fabulous, and I'm quite happy to see that it's already underway in > >> trunk. > >> I'm quite likely to be using a lot of development using Vaadin > >> framework in > >> the near future, which I expect probably stands to benefit > >> significantly > >> from SPDY. However, it seems that SPDY support in java is a wee > >> tad > >> nascent. As I understand it, there's an issue with oracle JDK > >> support for > >> NPN that is forcing tomcat to use APR. I also notice that Jetty > >> has just > >> released a version that supports SPDY using the NPN that is > >> apparently in > >> OpenJDK 7 already (will it appear in an oracle java update?). > >> Clearly this > >> is a key innovation, and it looks like between Apache Hhttpd and > >> Chrome/Firefox/Safari, more than 50% of the web will support it on > >> both > >> client and server merely by staying up to date with their current > >> software. > >> > > > > I have Jetty NPN working with tomcat - so NIO/BIO will also support > > SPDY. > > You will have to download/install the jetty implementation of npn > > jar > > yourself until it's merged into JDK7, don't know what are their > > plans. > > > > The APR seems faster - but not by a huge margin, I haven't tested > > the > > limits yet ( I want to find out what's the max number of kept-alive > > spdy > > connections - need more machines because of the 64k limit on local > > ports). > > > > > > > >> My question is this: will SPDY support be released in some form > >> before > >> Tomcat 8 (in who's branch it seems to currently live)? JSR 340 > >> (servlet > >> 3.1) seems to be targeting Q3 2012 and I would presume that that > >> means > >> tomcat 8 is no sooner than Q3 or Q4 - 2012. Seems a shame to make > >> this wait > >> until that time (assuming it's anywhere near ready). > >> > > > > I have a patch for tomcat7 to add only the NPN hooks - it's pretty > > small > > and clean, I'll get a discussion started, but it should be > > possible. > > > > Then it's up to tomcat-dev on whether to backport the spdy > > packages, or > > have tomcat7 download the spdy jars separately ( i.e. release them > > as a > > 'plugin' / add-on ). > > > > It'll take a bit of time until it's done - not easy to find free > > time to > > work on this. > > > > Costin > > > > > >> > >> -Gus > >> > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
