WildFly, Vaadin CDI i WebSockety

WidFly 8 posiada irytujące ograniczenie – wszystkie endpointy WebSocket muszą być wdrożone w trakcie inicjalizacji aplikacji webowej. W konsekwencji w aplikacji wykorzystującej oficjalną integrację frameworka Vaadin z CDI komunikacja pomiędzy częścią kliencką (uruchomioną w przeglądarce) i serwerową zamiast korzystać z WebSocket-ów  downgrade’uje  się do techniki long polling co ma negatywne konsekwencje (głównie wydajnościowe).
vaadin-long-polling

Problem ten i ogólne rozwiązane opisane są tutaj, ale w przypadku wykorzystania plugina integrującego Vaadina z CDI należy postąpić nieco inaczej.  Okazuje się, że wystarczy utworzyć własny servlet dziedziczący po klasie VaadinCDIServlet

import javax.servlet.annotation.WebServlet;

@WebServlet(
        loadOnStartup = 1, 
        urlPatterns = { "/*" }, 
        asyncSupported = true, 
        name = "vaadinCdiServlet")
public class WildFlyVaadinCDIServlet
 extends com.vaadin.cdi.server.VaadinCDIServlet {

}

i problem „magicznie” się rozwiązuje. Dlaczego to rozwiązanie działa?

Skomentuj

Wprowadź swoje dane lub kliknij jedną z tych ikon, aby się zalogować:

Logo WordPress.com

Komentujesz korzystając z konta WordPress.com. Log Out / Zmień )

Zdjęcie z Twittera

Komentujesz korzystając z konta Twitter. Log Out / Zmień )

Facebook photo

Komentujesz korzystając z konta Facebook. Log Out / Zmień )

Google+ photo

Komentujesz korzystając z konta Google+. Log Out / Zmień )

Connecting to %s