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 16:46:52 UTC
Back-porting JSR-356 Progress update
The JSR-356 API and implementation has been back-ported to Tomcat 7.
The necessary plumbing for the non-blocking support required by JSR-356
has been back-ported to Tomcat 7.
All compilation errors have been resolved.
The unit tests all pass.
Still to do:
1. Remove any Java 7 features so the code can compile with source -1.6
and target -1.6.
2. Add a check for Java 7 to the SCI so WebSocket is only loaded when
Tomcat 7 is running on Java 7 or later.
3. Add the WebSocket module into the build scripts.
4. Test with Autobahn.
5. Switch the WebSocket examples to the new API.
6. Deprecate the old HTTP upgrade and WebSocket implementations.
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 Progress update
Posted by Mark Thomas <ma...@apache.org>.
This is now complete.
As one of our community members has reported, Tomcat 7 trunk passes the
WebSocket 1.0 TCK with NIO.
I have also tested BIO, NIO and APR/native with Autobahn and all three
pass. I've added that (and a test I ran for 8.0.x at the same time) to
the Autobahn results on people.a.o [1]
I believe I have also fixed the intermittent unit test failures we were
seeing with the WebSocket tests.
Mark
[1] http://people.apache.org/~markt/dev/autobahn/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Back-porting JSR-356 Progress update
Posted by Mark Thomas <ma...@apache.org>.
On 22/08/2013 16:06, Niki Dokovski wrote:
> On Thu, Aug 22, 2013 at 5:47 PM, Mark Thomas <ma...@apache.org> wrote:
>
>> On 22/08/2013 15:30, Niki Dokovski wrote:
>>> On Thu, Aug 22, 2013 at 1:08 AM, Mark Thomas <ma...@apache.org> wrote:
>>>
>>>> Investigating some Gump and BuildBot failures has identified a large
>>>> block of functionality that still remains to be back-ported to 7.0.x -
>>>> namely the changes to Coyote that allowed upgraded connections to
>>>> support concurrent read and write.
>>>>
>>>> It isn't as simple as copy and paste as there has been some additional
>>>> refactoring particularly in the endpoints we probably don't want to
>>>> backport.
>>>>
>>>> Fixing this is top of my TODO list followed by getting Gump and Buidlbot
>>>> passing for 7.0.x and 8.0.x and then another 8.0.0 RC.#
>>>>
>>>> Mark
>>>>
>>>
>>> tomcat-7.0.43-dev revision 1516420 passes JSR 356 TCKs
>>
>> Excellent. Thanks for that update. With which connector(s)?
>>
>> (He asks knowing that the APR implementation is very likely to fail as
>> it needs the concurrent read/write changes back-ported from trunk).
>>
>
> Default without any additional configuration.
HTTP NIO then. Thanks again for a) testing it and b) reporting back the
result.
Mark
>
>>
>> I also want to run Autobahn against it but I have a few issues to fix
>> first.
>>
>> Cheers,
>>
>> Mark
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Back-porting JSR-356 Progress update
Posted by Niki Dokovski <ni...@gmail.com>.
On Thu, Aug 22, 2013 at 5:47 PM, Mark Thomas <ma...@apache.org> wrote:
> On 22/08/2013 15:30, Niki Dokovski wrote:
> > On Thu, Aug 22, 2013 at 1:08 AM, Mark Thomas <ma...@apache.org> wrote:
> >
> >> Investigating some Gump and BuildBot failures has identified a large
> >> block of functionality that still remains to be back-ported to 7.0.x -
> >> namely the changes to Coyote that allowed upgraded connections to
> >> support concurrent read and write.
> >>
> >> It isn't as simple as copy and paste as there has been some additional
> >> refactoring particularly in the endpoints we probably don't want to
> >> backport.
> >>
> >> Fixing this is top of my TODO list followed by getting Gump and Buidlbot
> >> passing for 7.0.x and 8.0.x and then another 8.0.0 RC.#
> >>
> >> Mark
> >>
> >
> > tomcat-7.0.43-dev revision 1516420 passes JSR 356 TCKs
>
> Excellent. Thanks for that update. With which connector(s)?
>
> (He asks knowing that the APR implementation is very likely to fail as
> it needs the concurrent read/write changes back-ported from trunk).
>
Default without any additional configuration.
>
> I also want to run Autobahn against it but I have a few issues to fix
> first.
>
> Cheers,
>
> 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 Progress update
Posted by Mark Thomas <ma...@apache.org>.
On 22/08/2013 15:30, Niki Dokovski wrote:
> On Thu, Aug 22, 2013 at 1:08 AM, Mark Thomas <ma...@apache.org> wrote:
>
>> Investigating some Gump and BuildBot failures has identified a large
>> block of functionality that still remains to be back-ported to 7.0.x -
>> namely the changes to Coyote that allowed upgraded connections to
>> support concurrent read and write.
>>
>> It isn't as simple as copy and paste as there has been some additional
>> refactoring particularly in the endpoints we probably don't want to
>> backport.
>>
>> Fixing this is top of my TODO list followed by getting Gump and Buidlbot
>> passing for 7.0.x and 8.0.x and then another 8.0.0 RC.#
>>
>> Mark
>>
>
> tomcat-7.0.43-dev revision 1516420 passes JSR 356 TCKs
Excellent. Thanks for that update. With which connector(s)?
(He asks knowing that the APR implementation is very likely to fail as
it needs the concurrent read/write changes back-ported from trunk).
I also want to run Autobahn against it but I have a few issues to fix first.
Cheers,
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 Progress update
Posted by Niki Dokovski <ni...@gmail.com>.
On Thu, Aug 22, 2013 at 1:08 AM, Mark Thomas <ma...@apache.org> wrote:
> Investigating some Gump and BuildBot failures has identified a large
> block of functionality that still remains to be back-ported to 7.0.x -
> namely the changes to Coyote that allowed upgraded connections to
> support concurrent read and write.
>
> It isn't as simple as copy and paste as there has been some additional
> refactoring particularly in the endpoints we probably don't want to
> backport.
>
> Fixing this is top of my TODO list followed by getting Gump and Buidlbot
> passing for 7.0.x and 8.0.x and then another 8.0.0 RC.#
>
> Mark
>
tomcat-7.0.43-dev revision 1516420 passes JSR 356 TCKs
Niki
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: Back-porting JSR-356 Progress update
Posted by Mark Thomas <ma...@apache.org>.
Investigating some Gump and BuildBot failures has identified a large
block of functionality that still remains to be back-ported to 7.0.x -
namely the changes to Coyote that allowed upgraded connections to
support concurrent read and write.
It isn't as simple as copy and paste as there has been some additional
refactoring particularly in the endpoints we probably don't want to
backport.
Fixing this is top of my TODO list followed by getting Gump and Buidlbot
passing for 7.0.x and 8.0.x and then another 8.0.0 RC.#
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 Progress update
Posted by Mark Thomas <ma...@apache.org>.
On 20/08/2013 06:35, Rainer Jung wrote:
> On 19.08.2013 15:22, Mark Thomas wrote:
>> I plan to commit what I have so far once I am happy that the unit tests
>> still work.
>>
>> I do want to look at removing the Java 7 dependency from the WebSocket
>> implementation - at least for Tomcat 7 - but I don't have the time to do
>> that immediately. Whether to implement this for Tomcat 7, Tomcat 7 & 8
>> or not at all will depend how complex the code ends up being. At the
>> moment I simply don't have a feel for it.
>
> Personal feeling: whoever starts to use the JSR-356 impl now on TC 7
> typically starts something new and should have no problem at all to
> directly base his project on Java 7. So if the build script dance works
> for the mixed Java version requirements I doubt that we gain a lot by
> removing the Java 7 specifics from the websocket code.
That is a fair point. It really comes down to how much effort is to
remove the Java 7 code. It were (if only!) say 10 lines I'd do it any way.
I think things are ready to commit but I still see some unit test
failures and I am working through them as it isn't clear if they are
genuine failures or a result of the back-port. The intermittent nature
of some of the3 unit test failures isn't helping. At least this exercise
is forcing me to take a closer look at them.
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 Progress update
Posted by Rainer Jung <ra...@kippdata.de>.
On 19.08.2013 15:22, Mark Thomas wrote:
> On 16/08/2013 15:46, Mark Thomas wrote:
> Updating the build script has proved "interesting". The WebSocket
> implementation depends on Tomcat internals but was also required to
> build the examples. That meant that the WebSocket build script was
> significantly intertwined with the main build script. There was also
> going to be a lot of duplication between the scripts.
>
> Therefore, I have opted to move the WebSocket code into the main code
> from modules and the build code into the main build script. Considering
> the problem we are trying to solve (DBCP must be built with Java 6,
> WebSocket must be built with Java 7) the changes required to handle this
> are pretty minor. Most of the build script changes are copied straight
> from Tomcat 8 and would be required regardless of the Java version used
> to build WebSocket.
>
> I plan to commit what I have so far once I am happy that the unit tests
> still work.
>
> I do want to look at removing the Java 7 dependency from the WebSocket
> implementation - at least for Tomcat 7 - but I don't have the time to do
> that immediately. Whether to implement this for Tomcat 7, Tomcat 7 & 8
> or not at all will depend how complex the code ends up being. At the
> moment I simply don't have a feel for it.
Personal feeling: whoever starts to use the JSR-356 impl now on TC 7
typically starts something new and should have no problem at all to
directly base his project on Java 7. So if the build script dance works
for the mixed Java version requirements I doubt that we gain a lot by
removing the Java 7 specifics from the websocket code.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Back-porting JSR-356 Progress update
Posted by jean-frederic clere <jf...@gmail.com>.
On 08/19/2013 03:22 PM, Mark Thomas wrote:
> I plan to commit what I have so far once I am happy that the unit tests
> still work.
Cool
Jean-Frederic
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Back-porting JSR-356 Progress update
Posted by Mark Thomas <ma...@apache.org>.
On 16/08/2013 15:46, Mark Thomas wrote:
> The JSR-356 API and implementation has been back-ported to Tomcat 7.
>
> The necessary plumbing for the non-blocking support required by JSR-356
> has been back-ported to Tomcat 7.
>
> All compilation errors have been resolved.
>
> The unit tests all pass.
>
> Still to do:
>
> 1. Remove any Java 7 features so the code can compile with source -1.6
> and target -1.6.
Done.
> 2. Add a check for Java 7 to the SCI so WebSocket is only loaded when
> Tomcat 7 is running on Java 7 or later.
Implemented locally and working but not committed.
> 3. Add the WebSocket module into the build scripts.
Done locally but not committed. Basics working. Still checking tests
execute correctly. See longer note below.
> 4. Test with Autobahn.
TODO.
> 5. Switch the WebSocket examples to the new API.
Done locally but not committed.
> 6. Deprecate the old HTTP upgrade and WebSocket implementations.
TODO.
Updating the build script has proved "interesting". The WebSocket
implementation depends on Tomcat internals but was also required to
build the examples. That meant that the WebSocket build script was
significantly intertwined with the main build script. There was also
going to be a lot of duplication between the scripts.
Therefore, I have opted to move the WebSocket code into the main code
from modules and the build code into the main build script. Considering
the problem we are trying to solve (DBCP must be built with Java 6,
WebSocket must be built with Java 7) the changes required to handle this
are pretty minor. Most of the build script changes are copied straight
from Tomcat 8 and would be required regardless of the Java version used
to build WebSocket.
I plan to commit what I have so far once I am happy that the unit tests
still work.
I do want to look at removing the Java 7 dependency from the WebSocket
implementation - at least for Tomcat 7 - but I don't have the time to do
that immediately. Whether to implement this for Tomcat 7, Tomcat 7 & 8
or not at all will depend how complex the code ends up being. At the
moment I simply don't have a feel for it.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org