I've decided to start from scratch since there are lots of concepts to map.
It was pretty trivial to get Tapestry to delegate to the Atmosphere servlet (or even the MeteorServlet) like tapestry-cometd does. That seems to work really well, so thanks for that! Next I wanted to be able to @Inject services into my handler class. I want to be able to write Atmosphere-based services the normal way, e.g. using @ManagedService. This scheme creates a ManagedAtmosphereHandler that calls into the class I've mapped to a specific URL. That all works, of course, but without @Inject support since nothing is going through the Tapestry IOC. I got it working with Atmosphere 2.0.0RC3 and then everything changed in RC4, but it appears cleaner. Basically, you duplicate the org.atmosphere.annotation.Processor classes for every type you wish to enable IOC support. (In my case, basically everything that class that uses Class.newInstance() and replace with Registry.autobuild(). It appears to work. Can anyone think of any potential problems, since I'm not all that comfy with the Tapestry IOC's internals)? I haven't started integrating broadcasters, broadcaster filters, or the like. I see that tapestry-cometd has done that, but I'm not really sure I need to since all the Atmosphere annotations should work. Norman Franke Answering Service for Directors, Inc. www.myasd.com On Sep 4, 2013, at 12:11 PM, Lance Java <lance.j...@googlemail.com> wrote: > I haven't done much research into Atmosphere… I found the docs to be quite > cryptic and couldn't quickly find what I wanted. > > tapestry-cometd relies on a few concepts, If atmosphere has these same > concepts then the switch will be easy, if not I guess it will be more > difficult. > > 1. A Push Session - A serverside Map that lives for the duration of a > subscription > 2. Wildcard channels (when I subscribe to "/chat/**" I will get messages > for /chat/cars and /chat/food/apples) > 3. Subscription listeners - notified of subsctibe and unsubscribe events > 4. Authorizers - permit / deny subscriptions > > Atmosphere suggests using annotations in most of the examples. CometD did a > similar thing. I found that I needed to use the services under the hood > instead of the annotations. I would assume that we would most likely use > the "under the hood" services in atmosphere
