Re: isAsyncStarted=true on ERROR dispatch

On Wed, Jul 13, 2016 at 12:46 PM, Rémy Maucherat wrote: > 2016-07-13 14:00 GMT+02:00 Violeta Georgieva : > > > Hi, > > > > I think the following part of the specification is important: > > > > " > > In the event that an asynchronous operation times out, the

Re: isAsyncStarted=true on ERROR dispatch

On Wed, Jul 13, 2016 at 8:00 AM, Violeta Georgieva <miles...@gmail.com> wrote: > Hi, > > 2016-07-12 23:27 GMT+03:00 Rossen Stoyanchev <rstoyanc...@pivotal.io>: > > > > hi- > > > > Starting with Tomcat 8.0.35 when an async request

isAsyncStarted=true on ERROR dispatch

hi- Starting with Tomcat 8.0.35 when an async request times out, in a subsequent error dispatch request.isAsyncStarted() returns true. Previously it returned false. The Servlet spec says: If this request has been dispatched using one of the AsyncContext.dispatch methods since it was put in

Re: [VOTE][RESULT] Release Apache Tomcat 9.0.0.M6

A bit late to this but I've done quick sanity checks from a Spring Framework perspective (framework tests, websocket, Servlet 3 async, Servlet 3.1 non-blocking) with no issues encountered. On Mon, May 16, 2016 at 6:34 AM, Mark Thomas wrote: > The following votes were cast: > >

Re: [VOTE] Release Apache Tomcat 8.5.2

On Wed, May 11, 2016 at 6:22 PM, Mark Thomas wrote: > The proposed Apache Tomcat 8.5.2 release is now available for voting. > > 8.5.2 corrects a regression found in 8.5.1. > > The major changes compared to the 8.5.0 release are: > - Add the org.apache.catalina.servlet4preview

Re: [VOTE] Release Apache Tomcat 8.5.0

hi, A public API for initiating an upgrade at runtime was removed [1] which breaks WebSocket support in the Spring Framework. This API was previously added to make up for a limitation in JSR-356. The hope was for it to be picked up in a spec update but unfortunately there has been no movement

Re: [VOTE] Release Apache Tomcat 8.0.1

On Wed, Jan 29, 2014 at 6:43 PM, Mark Thomas ma...@apache.org wrote: The proposed 8.0.1 release is: [ ] Broken - do not release [ ] Alpha - go ahead and release as 8.0.1 (alpha) [ ] Beta - go ahead and release as 8.0.1 (beta) [x] Stable - go ahead and release as 8.0.1 (stable) Focused

Re: [VOTE] Release Apache Tomcat 8.0.0

I can confirm that the issue with the empty Sec-WebSocket-Protocol header also affects Chrome 31.0.1650.63. The actual issue appears as an Invalid UTF-8 sequence in header value message in the Chrome dev tool. Although I had read what Martin reported for Chrome 32, I couldn't confirm it's the

Re: [VOTE] Release Apache Tomcat 7.0.45

On Wed, Sep 25, 2013 at 9:37 AM, Violeta Georgieva miles...@gmail.com wrote: The proposed Apache Tomcat 7.0.45 release is now available for voting. This release candidate contains JSR-356 Java WebSocket 1.0 implementation. Note that use of this functionality requires Java 7. It can be

Re: [VOTE] Release Apache Tomcat 7.0.44

I am getting a ClassCastException when using (non JSR-356) upgrade, i.e. WsServerContainer.doUpgrade: Caused by: java.lang.ClassCastException: org.springframework.security.web.servletapi.HttpServlet3RequestFactory$Servlet3SecurityContextHolderAwareRequestWrapper cannot be cast to

Re: [VOTE] Release Apache Tomcat 7.0.44

On Tue, Sep 24, 2013 at 11:40 AM, Mark Thomas ma...@apache.org wrote: Tomcat should already being the necessary unwrapping in lines 179-181. It isn't immediately clear to me why this isn't working as intended. Can you denug this and add some insight? Indeed, the code does unwrap the request

Re: [VOTE] Release Apache Tomcat 7.0.44

On Tue, Sep 24, 2013 at 11:40 AM, Mark Thomas ma...@apache.org wrote: The necessary update to the script that uploads those JARs to the Maven repo was missed. I think I have fixed it locally but need to test it from somewhere with connectivity. Unless the JavaOne Wifi is significantly better

Re: [Bug 55006] Add http proxy support for ClientEndpoint using system properties

On Mon, Jun 3, 2013 at 10:27 AM, Niki Dokovski nick...@gmail.com wrote: On Mon, Jun 3, 2013 at 3:44 PM, Niki Dokovski nick...@gmail.com wrote:Further on, if you choose to use connectToServer call that has the ClientEndpointConfig param you are losing the annotation approach as the first

TesterWsClientAutobahn failures

Is this expected to run successfully? I am seeing failures when running with `wstest -m fuzzingserver`. For example in 9.1.3, when the test client tries to send the message back, the fuzz server closes the connection with status 1007 and reason encountered invalid UTF-8 while processing text