Владимир Смирнов

Насколько я помню, для Java 8 рекомендуется Tomcat 8. Запускал Tomcat 8 под Java 8, разворачивал достаточно комплексное, сложное приложение - работало. Не стал использовать, т.к. первая же протестированная фича Java 8 не заработала в JSF (вина библиотек JSF, а не самого Tomcat). Ну и плюс мой хостинг пока предоставляет только Tomcat 7. Так что если есть возможность в продакшене развернуть Java 8 и Tomcat 8, то почему бы и нет?

Насчет контейнеров. Tomcat 8 - отличный сервер приложений, на котором можно развернуть практически любое приложение. Но делать это придется ценой самостоятельной интеграции различных фреймворков в свое приложение. Например, чтобы равзернуть веб-сервисы, потребуется разобраться как это сделать, возможно даже развернуть "движок" веб-сервисов. А вот в JBoss (или WildFly) уже развернуто множество фреймворков, и для того, чтобы развернуть веб-сервис, достаточно добавить в свои исходники нужные аннотации, а "движок" веб-сервисов там уже есть.

В более простом и легковесном Tomcat требуется больше усилий для того, чтобы подключать фреймворки к своему приложению, т.к. кроме непосредственно подключения к приложению, еще требуется развертывание самих фреймворков (обычно это не так уж и сложно, и в Гугле все есть).

Более "тяжелый" JBoss сделал часть работы за вас, но у этой работы есть своя цена. Во-первых, стек технологий и их версий жестко завязан на конкретную версию JBoss-а: если потребуется развернуть более свежую версию конкретного фреймворка или даже API библиотеки, в большинстве случаев это просто невозможно. Или если ваше приложение использует какое-то-API-v2.jar, а в JBoss-е уже активно используется какое-то-API-v1.jar, то нередко потребуются танцы с бубнами для решения проблем совместимости. Плюс настройки: нередко вместо стандартных настроек фреймворка придется разбираться с их JBoss-овским вариантом.

Таким образом, для сложных приложений JBoss может дать более быстрый старт, в сравнении с Tomcat-ом. Но впоследствии, когда после старта придет время специфических настроек и требований, JBoss может завести в тупик или, как минимум, заставить серьезно "забуксовать на ровном месте"

Я, пожалуй, посоветую все же Tomcat

Судя по тексту ошибки, сам класс HelloWorld забыли "положить" на сервер, либо он оказался в контексте, недоступном загрузчику классов, который загружает index.jsp. Т.е., либо класса вообще нет на сервере, либо он лежит там, откуда сервер его загрузить не догадался. В HelloWorld-ах классы обычно лежат в папке HelloWorld.war/WEB-INF/classes

А вообще, JSP - технология давно устаревшая, ее современный вариант - JSF. Начиная со второй версии спецификации создание собственных компонентов (аналог тегов JSP) стало простой задачей...

Несмотря на то, что на объектном уровне Hibernate требует объект Group, на самом деле ему для корректного сохранения в БД нужен лишь group_id. Можно создать пустой/фейковый (не считанный из БД) экземпляр Group и указать ему нужный вам group_id. После этого его можно смело передавать в user.setGroup(group); Если количество групп в Системе ограничено и все они известны заранее (подтекст вопроса это подразумевает), то можно хранить как константы экземпляры Group с заполненным полем ID.

JPA - это интерфейс языка JAVA, не имеющий реализации в самом языке. Если просто добавить аннотации JPA в свои классы, то не произойдет ровным счетом ничего. Для того, чтобы аннотации начали "работать", следует развернуть и настроить в проекте фреймворк, который "найдет" все классы с JPA-аннотациями и "состыкует" их с сущностями СУБД. Этим фреймворком у вас является Hibernate.

По поводу "работать с hibernate можно и через JPA или отдельно от него" - тут в основном дело вкуса. У вас есть два варианта сообщить Hibernate какие классы "замапить" на таблицы БД:
1. Добавить в классы аннотации JPA
2. Создать XML-файлы, в которых будет описано сопоставление классов объектам БД.

По доступной функциональности оба метода равны между собой, при этом аннотации JPA более современны. Я бы рекомендовал JPA, т.к. при открытии класса сразу будет видно, что он "замаплен", а в случае использования XML, "замапленный" класс визуально неотличим от других классов.

Скорее всего, операция загрузки завершилась ошибкой, а вы это не проверили. При возникновении ошибок, FTPClient не выбрасывает исключение, а просто сохраняет код ошибки, а вызванный метод возвращает false. При этом исполнение кода продолжается и доходит до корректного закрытия файла, из-за чего вы получаете файл размером 0 байт. Если retrieveFile вернул false, то смотрите ftpClient.getReplyString(), вместо того, чтобы корректно закрывать файл. Например, можно сделать так:

if(!isDownloaded) {
    throw new Exception(ftpClient.getReplyString());
}

При этом конечно не забывать об освобождении ресурсов в блоке finally пока что не существующего в методе блока try...

проект, состоящий из одного EJB и одного WAR

В JBoss (и в терминологии серверов приложений JEE в целом) нет понятия "проект". Правильно ли я понимаю, что под "проектом" подразумевается Enterprise Archive (EAR)? Если у вас нет EAR, то я не вижу способов считать чем-то единым отдельный WAR и отдельный EJB-модуль.

Если есть EAR, попробуйте в папку META-INF добавить файл с именем jboss-deployment-structure.xml со следующим содержанием:

<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
    <ear-subdeployments-isolated>false</ear-subdeployments-isolated>
</jboss-deployment-structure>

Создать EAR можно следующим образом. Создаете в папке deployments папку my.ear со следующей структурой:

my.ear
--META-INF
----application.xml
----jboss-deployment-structure.xml
--myWeb1.war
--myWeb2.war
--myEjb1.jar
--myEjb2.jar

Содержимое application.xml:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE application PUBLIC "-//Sun Microsystems, Inc.//DTD J2EE Application 1.3//EN" "http://java.sun.com/dtd/application_1_3.dtd">
<application>
    <display-name>myApp</display-name>
    <initialize-in-order>true</initialize-in-order>
    <module>
        <java>myEjb1.jar</java>
    </module>

    <module>
        <java>myEjb2.jar</java>
    </module>

    <module>
        <web>
            <web-uri>myWeb1.war</web-uri>
            <context-root>myWeb1</context-root>
        </web>
    </module>
    
    <module>
        <web>
            <web-uri>myWeb2.war</web-uri>
            <context-root>myWeb2</context-root>
        </web>
    </module>
</application>

Библиотеки, не содержащие EJB (просто "носители" нужных общих классов), можно поместить в папку my.ear/lib

GWT - один из лучших вариантов для такой задачи. Если у вас постоянные пользователи, то сгенерированный GWT-скрипт будет грузиться в браузер единожды, и в дальнейшем весь интерфейс будет рисоваться в браузере, без обращений к серверу. Обращения к серверу понадобятся только для получения/передачи чистых данных, без html/xml оберток, и делаться это будет только тогда, когда это действительно требуется вашей логике, т.е., далеко не каждое действие пользователя будет вызывать обращение к серверу. К тому же, можно кешировать часто используемые данные на клиенте, снижая трафик и нагрузку на сервер. Еще один плюс - очень много логики (например, сложный форматно-логический контроль) можно выполнять на клиенте, без обращений к серверу.

Насчет дизайна: в GWT есть минимальный набор компонентов, с помощью которого можно "нарисовать" динамический интерфейс любой сложности. Если ваша цель - не завлечь на сайт пользователей красивыми/необычными рюшечками, а создать функциональное рабочее место, то базовых компонентов должно хватить.

Кстати, тот же Vaadin работает на GWT. Он дополняет его своими компонентами, но убивает на корню один из главных плюсов GWT - высокую степень независимости от сервера во время действий пользователя.

Насчет нагрузки: 1000 человек, постоянно работающих в приложении, это много. Готовьте мощные сервера под СУБД и под сервер приложений, плюс держите в уме возможность развертывания кластера для распределения нагрузки.

Если Вы - Java-программист, то разрабатывать под GWT будет приятно, а точнее - как обычно. Например, процесс разработки под JSF - то ещё "удовольствие", GWT в этом плане гораздо лучше.

В среде разработки подключите в качестве библиотеки jar-источник декомпилированного класса

Абсолютное большинство услуг хостинга подразумевают возможность развертывания приложений, написанных на PHP, причем без доступа к веб-серверу. Это связано с тем, что они сами разворачивают веб-сервер, который обслуживает одновременно множество аккаунтов пользователей (т.е., много сайтов, принадлежащих разным владельцам, разворачиваются на одном веб-сервере). Если у вас приложение на PHP, то, скорее всего, Вам на самом деле не нужен Tomcat, можно обойтись стандартным PHP-хостингом.

Но, раз уж Вы написали вопрос в разделе Java, видимо требуется развернуть приложение на Java. Услуг хостинга таких приложений очень мало, в большинстве случаев приходится арендовать виртуальный (или даже "железный") сервер, и на нем разворачивать самостоятельно любую инфраструктуру. Но можно найти и альтернативы. В конце прошлого года компания Infobox анонсировала новый облачный хостинг с поддержкой Java, причем Tomcat у них уже преднастроенный, добавляется в пару кликов. У меня как раз Java-проект готовился к запуску, и я решил попробовать. Пошел второй месяц: полет нормальный, денег потрачено менее 300 рублей (правда и нагрузки большой пока не было). У них есть свой хаб на Хабре, найдите его среди компаний, почитайте - они в последнее время только про этот хостинг и пишут.