ServerPush
is an add-on for Vaadin that uses the excellent
Atmosphere Framework
to provide true server push using one of four methods:
- Blocking I/O
- Native Comet support in app server
- Servlet 3.0 Async
- WebSockets
Great job! I have several times been about to start a project on atmosphere, but my agenda have been way too full lately. I even had a name for it: OzoneLayer.
IMO you shouldn’t even provide the “push()” version, but to urge people to use the seamless mode instead. That really is the way to go. I haven’t looked at your code, but for DontPush (pure web socket implementation) I got it working quite fine with a thread that does the actual paint phase. That combined with using the application instance as a lock, updates should fire the paint phase only when “transaction” is done (but still practically instantly).
cheers,
matti
I haven’t tested it still, but it’s a good new more people interested in push technology.
I think an explicit push() call is a good idea, besides the seamless possibility.
I tested the other two push addons. One worked only with Jetty and one required the flash plugin installed case the browser didn’t support websockets.
The feature list seems comprehensive but I’m not sure which servlet containers brands an versions nor which browser brands and versions are supported.
Also, the documentation is very short. It’s not clear if it’s necessary to configure anything to force / prevent push methods, or if there is a fallback from the 4th to the 1st method by default.
Aniceto
The documentation is indeed very short; haven’t tried for real yet, but can you clarify if the instructions given are in addition to the rather more elaborate setups discussed in the white paper, or if have you really found a way to boil it down to three things (add the jars, add atmosphere.xml, tweak web.xml for two servlets ?), In any case, a bit more guidance would be most welcome.
The variety of servers and situations supported by atmosphere would make this a fine candidate for actual inclusion in the base product as the default (but leave “push()” in for w a while, it makes you add-on backward compatible with ICEPush without changing source 
)
Thanks for the kind words. I agree with you on the push() method; however, the automatic method can introduce a lot of overhead. For instance, if you have a selectable table then just clicking on a row will cause a repaint request. This might not be desired for some users.
I created this due problems I encountered with ICEPush and since we use Tomcat 7 using DontPush was out. My company also currently uses Atmosphere native comet with Tomcat 6/7 and it is very stable (not experimental like ICEPush). The servlet containers supported are:
- Tomcat 6
- Tomcat 7
- JBoss
- WebLogic
- Jetty
- Grizzly
- Resin
- Servlet 3.0 containers
I have currently tested this add-on with the following browsers:
- Firefox >= 3
- Chrome
- Safari
I plan to do more testing on different browsers, specifically IE, but I haven’t had time yet and IE is obviously not available on my Linux boxes.
I agree the documentation is short and I plan to update the add-on in the near future with full javadocs and complete examples. As for configuration, you can use the files in the “web/” directory in the add-on archive as a template. You will really just need to update the Vaadin servlet config init-params. This example is setup for servlet 3.0 configuration and automatic push on repaint requests. If you want to manually push to clients simply change the Vaadin servlet class to the default Vaadin servlet. Add the ServerPush widget to your application and call its push() method when you want to push to clients.
The transport mechanism is controlled by Atmosphere. Look in the example web.xml to see some options for configuring the transport mechanism. For instance, if you wish to use web sockets uncomment the servlet init-param
org.atmosphere.useWebSocket
and set value to true. To use native comet uncomment
org.atmosphere.useNative
and set value to true. To force the use of blocking I/O uncomment
org.atmosphere.useBlocking
and set value to true.
More documentation will be available soon. For now, here are simple steps to setup using automatic push:
- Add JARs in add-on archive to classpath (should also go in WEB-INF/lib)
- Add SLF4J to classpath (should also go in WEB-INF/lib)
- Create new widgetset if you do not already have a custom widgetset and inherit the
org.vaadin.addons.serverpush.ServerPushWidgetset
widgetset - Compile new widgetset as part of your build and add to the VAADIN/widgetsets/ directory in the root of your web application
- Add the contents of the “web” directory from the add-on archive; merging if you need to. Your web.xml should have both AtmosphereServlet and the add-on’s Vaadin servlet configured. atmosphere.xml should be in META-INF.
- Change servlet mapping for Vaadin servlet if you so desire, but leave the servlet mapping for AtmosphereServlet alone.
- Modify Vaadin servlet init-params to use your Application class and your custom widgetset
- Add the ServerPush widget to your Application (I add it as the last component of the main window).
- Perform some action on the server that changes state on the client (e.g. add a new item to a table’s container)
Hello all,
I just released version 1.0.1 of ServerPush. Here are the changes:
- Allow the specification of the context path for ServerPush widget
- Update ServerPushApplicationServlet to automatically add the ServerPush widget to the application
- Remove dependency on SLF4J
If you use the ServerPushApplicationServlet do not add the widget to you application instance; it will be added for you automatically.
Just released 1.0.2, which fixes a NPE when using ServerPushApplicationServlet
Added 1.0.3. See directory for change log.
What atmosphere artifacts are required?
I find it hugely frustrating that the Vaadin directory provides a pom download, but that pom doesn’t include what dependencies are actually required for the add-on to function.
Hi, Thomas. Thanks so much for this terrific add-on! I have a chat “sub-application” that appears to be working correctly when the context path is “/*” but I’m afraid I missing something when it comes to associating an alternative context path with the chat app so as to have multiple contexts handled by multiple applications. I would like to have the contexts like so:
main app at /main/*
chat app at /chat/*
I’m not using auto-push, so /main is a Navigator7 servlet, and /chat is a standard Vaadin servlet with listener-based “manual” push()es. I’ve tried what seems like every combination of context settings in atmosphere.xml, context.xml and web.xml. I’d be very grateful for any guidance from you or the group!
Best regards,
Elliott Wade
If an add-on jar uploaded to Directory contains a Maven pom file, Directory will use that. For more information, see
this
.
Hi Elliot,
Can you tell me more about your app? Are you using multiple web contexts or are
/main/*
and
/chat/*
in the same context? and if so, what is that context? i’ll be happy to provide you the correct config if you can supply me this information. Here is an example assuming you are using manual push and the context path of your app is /foo.
- You can copy the atmosphere.xml and web.xml from the zip file as templates. This will make the URL for push
/foo/server-push
- Now use the constructor of ServerPush that accepts a String value, which is set as the context path. Since the context path of the web application is
/foo
, call
new ServerPush(“/foo”)
- Everything should work fine now
The important thing is to match the context path constructor param to the AtmosphereServlet’s servlet mapping url pattern (minus
/server-push
). Please note that this path is
independent
of the Vaadin application path; thus, you can have
/chat/*
point to the Vaadin app and
/push/server-push
configured for the atmosphere servlet. Using this path the servlet mapping url pattern in web.xml for the AtmosphereServlet would be
/push/server-push
, the
context-root
attribute in atmosphere.xml would be the same, and you would instantiate the ServerPush widget using
new ServerPush(“/push”)
.
Being able to specify the context path in the ServerPush constructor is powerful as you do not have to actually specify the exact context path. Here’s another example (assume context path is /web:
In
WEB-INF/web.xml
:
....
<servlet-mapping>
<servlet-name>AtmosphereServlet</servlet-name>
<url-pattern>/foo/bar/baz/somethinghere/longURL/server-push</url-pattern>
</servlet-mapping>
....
In
META-INF/atmosphere.xml
:
....
<atmosphere-handlers>
<atmosphere-handler context-root="/foo/bar/baz/somethinghere/longURL/server-push" class-name="org.vaadin.addons.serverpush.VaadinServerPushHandler">
<property name="heartbeat" value="5000"/>
</atmosphere-handler>
</atmosphere-handlers>
....
In your app:
....
ServerPush push = new ServerPush("/web/foo/bar/baz/somethinghere/longURL");
....
application.getMainWindow().addComponent(push);
....
// something happens
push.push();
....
So the URL mapping is really irrelevant as long as the config files match and you are using manual push. This cannot currently be done with automatic push as it always uses
/server-push
as the path; however, if there is enough interest i can add that in.
Hope this helps you Elliot. Send me any questions you may have.
Henri, is there any way to view what is currently in the Vaadin Maven repo? Does Vaadin copy the dependencies into its own Maven repo or does it just copy the dependencies section of the pom.xml so the dependencies are retrieved from Maven central or any other configured repo?
Why would the content of the Vaadin repository matter ? If Vaadin and atmosphere are in the Maven Central repository (which they are), your POM should not include any repository directives (same goes for the usual common-* libraries and suchlike that your code directly depends on).
Also, your POM should likely mark Vaadin as optional – whoever includes your add-on should be responsible for deciding which version they want
This stems from my ignorance of Maven, which I do not use. I’m an Apache Ivy guy ;0) As this add-on stands right now, the user is free to pull-in whichever version of Vaadin they want as well as other libraries. I like that better as it is more flexible for developers. For those Ivy users, you can find this add-on in the
Ivy RoundUp
repository.
Hi,
I am using this add on. It works fine on Tomcat 6.0.33 but gives the following error on Tomcat 7.0.22
WARNING: failed using comet support: org.atmosphere.container.TomcatCometSupport, error: Tomcat failed to detect this is a Comet application because context.xml is missing or the Http11NioProtocol Connector is not enabled.
If that’s not the case, you can also remove META-INF/context.xml and WEB-INF/lib/atmosphere-compat-tomcat.jar
O
What extra do I need to do to make it working on Tomcat 7
I am using this with Tomcat 7.0.21 using Servlet 3.0 with no special config. Make sure your context.xml has the child element
. It that does not solve your problem please send me your config and I can guide you.
I am using context.xml with this loader element in META-INF
One difference is that I am not using Servlet 3.0. Does it have to be servlet 3.0? If that is the case what do I need to do to covert to servlet 3.0?