It really depends how Atmosphere is initialized. If I got the code right these are following main alternatives:
1) MeteorServlet: in this case the value of <MAPPING = "org.atmosphere.mapping";> (check ApplicationConfig.java) defined in web.xml is used as AtmospherHanlder's mapping (and also the corresponding broadcaster message)
In this case you can define various AtmosphereHandler(s) using atmosphere.xml e.g.
<atmosphere-handler context-root="/twitter" class-name="org.atmosphere.samples.twitter.TwitterAtmosphereHandler"/>
<property name=”” value=””/>
(the context-root is the mapping)
there are also other alternatives but I am really no profi in that matter I must also confess that I don't have a very deep understanding of Atmosphere, but If I got it right, each time an AtmosphereHandlerWrapper is created a broadcaster with the mapping of AtmosphereHandler is created and is stored in the wrapper. So I would suggest is to try looking up the root broadcaster (/*) and if not found try to get all broadcasters and find a suitable one.
About the multiple boradcasters: I am also not sure if that would make sense in the context of Wicket (at least not with this implementation), since you have a very robust subscription (with @Subscribe) and filtering mechanism which makes different broadcasters for different AtmosphereResources unnecessary. Event multiple AtmosphereHandlers for different mappings would be superfluous.
A very simple workaround would be to use "public Broadcaster lookup(Class<? extends Broadcaster> c, Object id, boolean createIfNull);" method of default broadcaster factory and set "createIfNull" to true. This way you would make sure that you'd get always a root broadcaster.