I just saw your post in the 'integration' forum.
I have not tried to use Spring Integration for this,
but went straight to JMS (planning for horizontal scaling)
you can see the result in http://atmosphere-users-mailling-lis...5p5721315.html
Atmosphere is a good start, but it is a bit confusing and over-engineered as it is not simply a client/server comet adapter.
As often happens, its primary demo/use-case has caused Atmosphere to expand into being its own messaging service.
I took the approach to use as little of Atmosphere as possible, and use ApacheMQ/JMS for messaging.
So my client opens one long-polling comet request to get events,
and continues to use normal HTTP through Spring Controllers for everything else,
when server wants to pass a message/event to the client, it just sends a JMS message (using jmsTemplate)
The JMS message is received in MyJMSBroadcaster which pushes it to the client.
[the client can do DOM surgery or reload to get a new view]
Next step is to configure the listener in MyJMSBroadcaster to list to both the per-user queue and other topics.
But in all cases, the JMS message will simply use Atmosphere to push back to the client.
Note: my AtmosphereServlet is configured independently in web.xml, and it not using any of the spring features.
The comet connect arrives to the AtmosphereHandler with the same JSESSIONID set, so we can:
and check for an authenticated Principal from there.
SecurityContext context = (SecurityContext)session.getAttribute("SPRING_SECURITY_CONTEXT");
Other than that, the AtmosphereHandler just sets up the JMSBroadcasters (which are configured through spring)
And alas, I'm using a Roo-based server-side, so it is tomcat-6 and dojo,
which is not perfectly aligned with atmosphere's target of jquery and web-socket;
(and eventually tomcat may get other transport support, or we can insert jetty or something,
but long-polling is good enough for the eventing that I currently need)