Как смешать Java-сервлеты с веб-сокетами Play Framework?

Question

Как смешать Java-сервлеты с веб-сокетами Play Framework?

1

Я хочу смешивать стандартное приложение J2EE и играть в веб-сокеты. Оба написаны в Scala.

Мне удалось получить код веб-сокета Play для компиляции с моим кодом J2EE Scala, включив некоторые из банок из дистрибутива платформы Play. Тем не менее, я не могу понять, как получить обработчик веб-сокета Play для прослушивания соединений.
Я обычно запускаю приложение с помощью Jetty (java -jar jetty-runner.jar myapp.war)

Я не против запуска приложения через play run процесс, пока я могу использовать как сервлеты, так и Play web-socket.

Есть ли лучшее решение, чем запуск двух приложений в отдельных контейнерах?

Приложение J2EE использует HTML, JSP, сервлеты и JDBC.

Jus12 27 сен. 2014, в 05:55

Источник

0

Можете ли вы расширить свою мотивацию? Самым простым способом было бы держать ваши приложения отдельно и сделать так, чтобы nginx давал «единый фронт HTTP» на всех ваших HTTP-серверах.
Andrew E 28 сен. 2014, в 10:01
0

@AndrewE У меня есть полностью разработанное приложение J2EE, и я хочу добавить в него некоторые функции веб-сокета. Я предпочитаю код Play для этого, а не альтернативы, потому что он очень чистый. Тем не менее, я не хочу использовать Play'ify для всего моего приложения, поскольку это потребует слишком больших усилий.
Jus12 29 сен. 2014, в 05:33
0

Хм. Я бы не советовал разыгрывать все ваше приложение, а просто сохранить основные компетенции там, где они есть: ваше приложение J2EE остается таким, как есть, и добавить новое небольшое приложение для веб-сокетов Play. Сначала используйте nginx, чтобы вызывающие абоненты обращались к одному хосту: порт; некоторые URI направлены на J2EE, а некоторые на Play / WS. Конечно, есть плюсы и минусы с этим, но это делает вещи простыми, отдельными и понятными.
Andrew E 29 сен. 2014, в 08:44
0

@AndrewE Тогда возникает вопрос о том, как они будут общаться. Веб-приложение генерирует данные, которые веб-сокет должен нажать. Поэтому мне придется создать интерфейс между ними (что выполнимо с некоторыми усилиями).
Jus12 25 окт. 2014, в 05:27
0

Правда достаточно. Но несколько мыслей (FWIW): должно ли веб-приложение генерировать данные, а не третий сервис? Если долгосрочная архитектура является третьим сервисом (т.е. создание данных может не соответствовать тому, что должно делать веб-приложение), то оно может отправить msgs в rabbitmq, а «живое обновление» (play) прослушивает mq и отправляет через веб-сокеты. , Если это так, то временная арка может быть в том, что веб-приложение отправляет обновления через mq. Я вас уверяю, это немного больше, чем вам нужно сейчас, но мне нравится руководствоваться «космическими захватчиками»: стреляйте туда, где идет проблема, а не здесь, это прямо сейчас!
Andrew E 25 окт. 2014, в 05:59

Показать ещё 3 комментария

Теги:

java

servlets

scala

playframework

playframework-2.0

1 ответ

Ещё вопросы

Можете ли вы расширить свою мотивацию? Самым простым способом было бы держать ваши приложения отдельно и сделать так, чтобы nginx давал «единый фронт HTTP» на всех ваших HTTP-серверах.
@AndrewE У меня есть полностью разработанное приложение J2EE, и я хочу добавить в него некоторые функции веб-сокета. Я предпочитаю код Play для этого, а не альтернативы, потому что он очень чистый. Тем не менее, я не хочу использовать Play'ify для всего моего приложения, поскольку это потребует слишком больших усилий.
Хм. Я бы не советовал разыгрывать все ваше приложение, а просто сохранить основные компетенции там, где они есть: ваше приложение J2EE остается таким, как есть, и добавить новое небольшое приложение для веб-сокетов Play. Сначала используйте nginx, чтобы вызывающие абоненты обращались к одному хосту: порт; некоторые URI направлены на J2EE, а некоторые на Play / WS. Конечно, есть плюсы и минусы с этим, но это делает вещи простыми, отдельными и понятными.
@AndrewE Тогда возникает вопрос о том, как они будут общаться. Веб-приложение генерирует данные, которые веб-сокет должен нажать. Поэтому мне придется создать интерфейс между ними (что выполнимо с некоторыми усилиями).
Правда достаточно. Но несколько мыслей (FWIW): должно ли веб-приложение генерировать данные, а не третий сервис? Если долгосрочная архитектура является третьим сервисом (т.е. создание данных может не соответствовать тому, что должно делать веб-приложение), то оно может отправить msgs в rabbitmq, а «живое обновление» (play) прослушивает mq и отправляет через веб-сокеты. , Если это так, то временная арка может быть в том, что веб-приложение отправляет обновления через mq. Я вас уверяю, это немного больше, чем вам нужно сейчас, но мне нравится руководствоваться «космическими захватчиками»: стреляйте туда, где идет проблема, а не здесь, это прямо сейчас!

dre-hh · Answer 1 · 2014-09-27T07-42-00.000Z

Play использует sbt для этой системы сборки. Я бы сказал, что самый простой способ достичь вашей цели woudld работать наоборот, придерживаясь sbt для компиляции и создания обоих - проект Servelet и проект play2. Sbt компилирует scala и java-источники просто отлично, если каталоги настроены правильно. Поскольку play2 уже генерирует правильную конфигурацию sbt build, вам нужно всего лишь подключить в нее конфигурацию сборки сервлета. Sbt имеет несколько плагинов для специальных задач, и в этом случае вы можете использовать x-sbt-webplugin.