Vaadin 7.1 and Push

Vaadin 6 / 7 / 8
1

I comment on the Blog Post, but i see its better to open a thread here in the forum.

Nice to see Push support.
Are there some Best Practice or thoughts to deal with threadlocal vars.
e.g. SpringSecurity uses this (and other) Atmophere on Tomcat (with or without servlet 3.0 async) do not call filters on websocket connection.

I am curious how to deal with this, maybe there are some thoughts about it.
By the way, i am not dig deep to push so maybe there are some handlers, callbacks, listeners or something - short google does not find infos about it.

2

Please add the possibility to use a custom PushHandler to allow doing some stuff (like, Threadlocal init, Security, filters, etc.) during atmosphere onRequest.

It’s very hard to get some own stuff in code now.

my try was:

I wrote an own VaadinServletService and override requestStart/requestEnd to add some own listener.

The own VaadinService is created in my own VaadinServlet with overidden createVaadinServletService method.

How would you do this. With activated Push a lot Wiki and Book examples would not work with asyn servlet 3.0 request anymore. Like Hibernate Session in View.
Examples with Security and so on. With activated Push the whole client/server communication is done with atmosphere (do not get me wrong, it’s good and i like it). if client/server allow async/websockets no filter is called anymore so we need a way to do similar stuff

3

Some proposials for 7.1 Beta and Push.
Is there already a Discussion Thread where we can give Feedback to 7.1 - the ticket system doesn’t seam right for discussions.

Proposals:

  • Make internal protected Method in PushRequestHandler to create the PushHandler (give us the possibility to extend and override)
  • Same as above for PushRequestHandler in VaadinServletService
  • better a wrapper/interceptor (something like filters) for the onRequest method in PushHandler to reqiester to
4

Some character Encoding issues - has anyone else this.

TextArea field with input ääääöööööüüüü resolv in “äääööööüüüü” set immideate.

Using Tomcat 7 with Apache in front and activated AJP (by the way - AJP can not pass websockets through so long polling fallback is used - tomcat 7 driekt would have used websockets. do not know if the issue exist there as well.)

Here is some captured communication with chrome:

Query String Parametersview sourceview URL encoded

v-uiId:9
v-csrfToken:b7c72c9e-dd9d-4fb8-a421-5a76dc7253b1
X-Atmosphere-tracking-id:644181a3-6250-4a64-8089-24efcc782367
X-Atmosphere-Framework:1.0.12
X-Atmosphere-Transport:polling
X-Cache-Date:0
Content-Type:application/json; charset
_:1368373955241

Request Payload

b7c72c9e-dd9d-4fb8-a421-5a76dc7253b1[[“832”,“v”,“v”,[“text”,[“s”,“äääööööüüüü\n\n”]
]],[“832”,“v”,“v”,[“c”,[“i”,“11”]
]]]

Response Headersview source

Connection:Keep-Alive
Content-Length:0
Content-Type:text/plain
Date:Sun, 12 May 2013 15:52:33 GMT
Keep-Alive:timeout=15, max=99

5

Thanks for the feedback! Yes, the push backend API is pretty much internal-only currently and not very extensible. We’ll see what we can do to improve the situation.

Currently, to catch Atmosphere requests, you can write an AtmosphereInterceptor and register it in web.xml:

package com.example;

import org.atmosphere.cpr;

class MyAtmosphereInterceptor extends AtmosphereInterceptorAdapter {
    public Action inspect(AtmosphereResource r) {
         // do pre-request stuff
         return super.inspect(r);
    }
    public void postInspect(AtmosphereResource r) {
         // do post-request stuff (Vaadin request handling is done at this point)
    }
}

[/code][code]
<init-param>
    <param-name>org.atmosphere.cpr.AtmosphereInterceptor</param-name>
    <!-- comma-separated list of fully-qualified class names -->
    <param-value>com.example.MyAtmosphereInterceptor/param-value>
 </init-param>
6

Any progress on this? The interceptors are not enough for us. I would call this a blocker.
I have checked the milestones and do not see any tickets for this in the near future and last comment was 5 months ago.

7

Hi, session access listeners (ticket
#12256
) should help in implementing most of these use cases. Opening PushRequestHandler up a bit for extension is still not a bad idea; there didn’t seem to have a ticket about it so I created
#12717
. In general, creating tickets about issues is more likely to get the dev team’s attention - forum posts are easy to forget.