Давайте представим, что ваша компания попросила разработать приложение для чата в реальном времени и хотела, чтобы это было завершено за несколько часов. Поскольку вы уже знаете, что с Node.js это очень просто, вы разработали его в Node.js, но компания использует серверы приложений Java (такие как WebSphere, JBoss или WebLogic).
Таким образом, администратор сервера ожидает развертывания файлов .EAR.
Есть ли способ предоставить файл .EAR, который запускает ваше приложение Node.js?
это настолько чертовски грязно, что любые вменяемые проверки выпущенного EAR должны убить вас на месте. это, как говорится, да, это возможно. Вы должны знать немного вещей в первую очередь.
является ли целевая JVM достаточно привилегированной для запуска процессов или безопасности с правами на выполнение, достаточно слабой, чтобы позволить JVM выполнять процесс оболочки с использованием своих методов API. (я говорю о безопасности Java, а не о безопасности ОС)
вы должны из первых рук точно знать, на каком типе ОС работает ушной контейнер.
EAR/WAR должен быть «расширен» до реальной файловой системы, известной ОС.
вы должны знать, имеют ли учетные данные, под которыми контейнер уха, достаточные права для выполнения команды ОС.
как только вы точно знаете эти четыре пункта, нет ничего страшного в том, чтобы использовать API-интерфейс Process java для выполнения процесса Node.js, который исполняемый файл (статически связанный и совместимый с ОС) удобно находится в известной позиции...
даже как сказал Бруно Гридер, совместное использование порта невозможно, поэтому веб-приложение будет выступать в качестве переднего прокси-сервера для «настоящего» приложения, работающего на Node.js, HTTP или HTTPS, которое вообще не имеет значения в качестве окончательного сообщения. между контейнером веб-приложения и самим веб-приложением больше не шифруется.
ооооо... так мило... :) но вы должны знать, что использование такого подлого метода в корпоративной среде - не очень хорошая вещь.
No.
Вы не можете правильно упаковать «предустановленный» nodeJS внутри уха.
Установка NodeJS отличается в Windows и Linux; EAR не будет портативным.
Кстати, я бы не хотел быть на вашем месте, если администраторы сервера узнают, что вы упаковываете исполняемые файлы, не предназначенные для запуска на JVM, внутри EAR.
(примечание 1: как отмечено в комментариях @mlan выше, было бы невозможно совместно использовать порты между процессом JVM и nodejs - для его подделки потребуется внешний обратный прокси-сервер, отправляющий HTTP-запросы, при условии, что весь трафик является HTTP)
(примечание 2: не поймите меня неправильно, вы можете поместить что угодно в EAR, включая исполняемые файлы, которые вы запускаете из Java, например, с помощью ProcessBuilder, но это крайний обходной путь)
