You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2013/08/16 00:47:27 UTC
Back-porting JSR-356 implementation to 7.0.x
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.
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.
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
Comments?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Back-porting JSR-356 implementation to 7.0.x
Posted by Mark Thomas <ma...@apache.org>.
Nick Williams <ni...@nicholaswilliams.net> wrote:
>
>On Aug 15, 2013, at 5:47 PM, Mark Thomas wrote:
>> 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
>>
>> Comments?
>
>Sounds workable. Not ideal. But workable.
Indeed. I'm currently unsure how I am going to handle the incompatible
upgrade mechanisms at this point. Side by side would be simplest but it
depends on what that does to the low level connector code.
>Getting the SCI compiled to be executable shouldn't be a problem. Just
>compile the module -source 1.6 -target 1.6 on Java 7. As long as you
>don't use Java 7 language features, you can still compile against the
>APIs.
The Java 7 features used are minimal ( <> and multi-catch). I'd prefer
to keep them to make keeping the code in sync with 8 simpler but that
would create a more "interesting" build. I guess they'll be being removed.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Back-porting JSR-356 implementation to 7.0.x
Posted by Nick Williams <ni...@nicholaswilliams.net>.
On Aug 15, 2013, at 5: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.
> 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.
>
> 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
>
> Comments?
Sounds workable. Not ideal. But workable.
Getting the SCI compiled to be executable shouldn't be a problem. Just compile the module -source 1.6 -target 1.6 on Java 7. As long as you don't use Java 7 language features, you can still compile against the APIs.
Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Back-porting JSR-356 implementation to 7.0.x
Posted by Niki Dokovski <ni...@gmail.com>.
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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: Back-porting JSR-356 implementation to 7.0.x
Posted by Mark Thomas <ma...@apache.org>.
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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Back-porting JSR-356 implementation to 7.0.x
Posted by Niki Dokovski <ni...@gmail.com>.
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?
It's preferable to keep the implementations in Tomcat 7 and Tomcat 8 as
close as possible.
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: Back-porting JSR-356 implementation to 7.0.x
Posted by Mark Thomas <ma...@apache.org>.
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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Back-porting JSR-356 implementation to 7.0.x
Posted by Niki Dokovski <ni...@gmail.com>.
On Fri, Aug 16, 2013 at 4:34 AM, Christopher Schultz <
chris@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?
>
> > 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?
> 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.
>
> Maybe we could package JSR-356-for-Tomcat7 as an optional module that
> has a Java 7 prerequisite?
>
+1 for making it optional and Java 7 dependent in Tomcat 7
Keep it simple if possibble
Java 7 is slowly adopted in productive environments anyway. One reason is
EOL
http://www.oracle.com/technetwork/java/eol-135779.html
> -chris
>
>
Re: Back-porting JSR-356 implementation to 7.0.x
Posted by Christopher Schultz <ch...@christopherschultz.net>.
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?
> 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?
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.
Maybe we could package JSR-356-for-Tomcat7 as an optional module that
has a Java 7 prerequisite?
-chris
Re: Back-porting JSR-356 implementation to 7.0.x
Posted by Mark Thomas <ma...@apache.org>.
On 16/08/2013 14:38, Rossen Stoyanchev wrote:
> On Thu, Aug 15, 2013 at 6:47 PM, Mark Thomas <ma...@apache.org> 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.
>> 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.
>
> If at all feasible, could applications using the server side only use Java 6?
Not without some potentially quite extensive refactoring because of the
way the Server implementation extends the client implementation. It
might be possible but given the EOL status of Java 6 it isn't that high
on my list of priorities.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Back-porting JSR-356 implementation to 7.0.x
Posted by Rossen Stoyanchev <rs...@gopivotal.com>.
On Thu, Aug 15, 2013 at 6:47 PM, Mark Thomas <ma...@apache.org> 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.
> 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.
If at all feasible, could applications using the server side only use Java 6?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org