Какова конфигурация java/scala, необходимая для интеграции Atmosphere (версия 1.0.13)?

Question

Я уверен, что это что-то довольно простое, но я не могу вспомнить, как сталкивается библиотека, которая имеет больше расхождений между ее документами, API и версиями. (Хотя, честно говоря, я уверен, что они существуют!) Насколько я могу судить по ресурсам, которые я просматривал, я думаю, что это довольно близко к «текущему», но я получаю сообщение об ошибке (карты No AtmosphereHandler запрос/path/to/service/point), и вам нужно небольшое руководство относительно того, что я должен попробовать дальше.

я могу повторно опубликовать подробную версию, но в общем ...

1) web.xml имеет эту запись сервлета (от последней мерзавец чата образца):

<servlet> 
    <description>AtmosphereServlet</description> 
    <servlet-name>AtmosphereServlet</servlet-name> 
    <servlet-class>org.atmosphere.cpr.AtmosphereServlet</servlet-class> 
    <async-supported>true</async-supported> 
    <init-param> 
     <param-name>org.atmosphere.cpr.Broadcaster.supportOutOfOrderBroadcast</param-name> 
     <param-value>false</param-value> 
    </init-param> 
    <!--<init-param>--> 
    <!--<param-name>org.atmosphere.cpr.broadcasterClass</param-name>--> 
    <!--<param-value>org.atmosphere.util.SimpleBroadcaster</param-value>--> 
    <!--</init-param>--> 
    <load-on-startup>0</load-on-startup> 
</servlet> 
<servlet-mapping> 
    <servlet-name>AtmosphereServlet</servlet-name> 
    <url-pattern>/path/to/service/point</url-pattern> 
</servlet-mapping> 

2) веб-приложение имеет следующее определение класса (в Scala):

@AtmosphereHandlerService(path = "/path/to/service/point") 
class MyCustomAtmoHandler extends AtmosphereHandler with Logging with OtherStuff { 
    override def onRequest {...} 
    override def onStateChange {...} 
    override def destroy {...} 

Примечание: документ, я использовал в качестве руководства не содержит параметр аннотации «пути» - который я должен был добавить, чтобы получить его компилировать.

EDIT: Это использование Jetty версии 9.0.4.v20130625

Answer 1

В ответ на мои собственные вопросы (в случае, если какой-либо другой блуждающих единственным находит себя в том же положении), я должен был сделать две вещи, чтобы решить проблема:

1) отмените аннотацию AtmosphereHandlerService или, по крайней мере, параметр «путь». (Можно было бы работать аннотацию, используя остальные параметры, не уверен.)

2) добавить файл с именем atmosphere.xml в папку META-INF, который содержит что-то вроде:

<atmosphere-handlers> 
    <atmosphere-handler support-session="false" 
        context-root="/websocket/path/to/processorA" 
        class-name="com.some.className"> 
    </atmosphere-handler> 

    <atmosphere-handler support-session="true" 
        context-root="/websocket/optional/path/to/processorB" 
        class-name="com.some.other.className"> 
    </atmosphere-handler> 
</atmosphere-handlers> 

Итак ... web.xml (или любой другой файл/архитектура развертывания, используемый вашим контейнером сервлетов) создает «общий» контекст для всех обработчиков ALL, тогда как определенные маршруты привязаны к каждому отдельному обработчику, используя разметку atmosphere.xml. (Что-то вроде «/ WebSocket/*» должно позволить маршрутизации оба этих гипотетических обработчиков.

Там, наверное, лучшие способы о том, этом решении с технической точки зрения, но мы надеюсь, который неспециалист сводных очков вы в правильном направлении.