On Fri, Aug 16, 2013 at 11:01 AM, Mark Thomas <ma...@apache.org> wrote:
> On 16/08/2013 08:16, Niki Dokovski wrote: > > On Fri, Aug 16, 2013 at 9:54 AM, Mark Thomas <ma...@apache.org> wrote: > > > >> Christopher Schultz <ch...@christopherschultz.net> wrote: > >>> Mark, > >>> > >>> On 8/15/13 6:47 PM, Mark Thomas wrote: > >>>> This isn't going to be quite as simple as I first thought. > >>>> > >>>> The WebSocket client API requires Java SE 7 or later. > >>>> The WebSocket server API requires Java EE 6 or later. > >>>> Java EE 6 requires Java 6 or later. > >>> > >>> Clarification: are you saying that Java EE requires that it be allowed > >>> to run on JVMs as low as Java 6? > >> > >> Java EE 6 is the version Tomcat 7 uses. > >> > >>>> The WebSocket server API depends on the WebSocket client API. > >>>> > >>>> The WebSocket client implementation makes extensive use of new Java 7 > >>>> non-blocking IO features. > >>> > >>> Are any of these possible (albeit with some back-flips) with Java 6? > >> > >> The first thing I thought of. It is possible but would require a > selector, > >> poller and thread pool implementation plus associated plumbing. Java 7 > >> looks like the better option at this point. > >> > >>> Perhaps one class (Java7NioShims) could be replaced with another > >>> implementation (Java6NioShim) at runtime depending upon the current > >>> JVM? > >>> I know nothing about the code involved... just stabbing in the dark. > >>> > >>>> My conclusion from the above is that the back-port is going to > >>> require > >>>> Java 7. That begs the question how to do that while keeping the main > >>>> build Java 6 based. > >>>> > >>>> My (untested) plan is as follows: > >>>> - Create a WebSocket module > >>>> - Back-port (i.e. copy) the trunk code to that module > >>>> - Build just that module with Java 7 > >>>> - Make the minimum changes necessary to get it to work > >>>> - Modify the back-ported SCI so it only adds the filter if Java 7 is > >>>> detected (going to need to ensure the SCI is executable on Java 6) > >>>> - Ship Tomcat 7 with the WebSocket JARs > >>> > >>> I'm not sure there's a better way, but the whole > >>> compile-one-module-with-a-higher-version thing has been a small thorn > >>> in > >>> the past (IIRC, Tomcat 6 had to be built with Java 6, but could be run > >>> with Java 5) causing a mild amount of confusion. If this could be > >>> avoided, I think it might be best. > >> > >> I know. I'm trying to find the minimum effort, minimum risk, minimum > >> hassle solution but there isn't a perfect solution that I can see. > >> > >>> Maybe we could package JSR-356-for-Tomcat7 as an optional module that > >>> has a Java 7 prerequisite? > >> > >> I'd really like to ship JSR-356 suport as standard. > >> > > > > How about making Java 7 hard requirement for releases that include JSR > 356 > > implementation? Is this OK? > > No. Tomcat 7 needs to run on Java 6. I think it is doable with a little > hoop jumping. Lets see what a first solution looks like and worry about > better solutions if we need one. > OK. The implementation in Tomcat 8 is well tested and we need to do the same for Tomcat 7. niki > > Mark > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
