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

Думаю, что вам нужен one-to-many на самом деле, т.е. в сущности User хранится список сущностей Achievement. При этом сущность Achievement имеет поля, описывающие конкретное достижение конкретного пользователя (дата получения и другие параметры), а также ссылку на тип достижения (следующий уровень one-to-many). По поводу Set/List - как объявите в классе так и будет, но для сортировки требуется указать order-by в .hbm.xml.

Примерно так:

public class User {
    private List<Achievement> achievements;
    get...
    set...
}

public class Achievement {
    private User user;
    private Date createDate;
    private DicAchievementType type;//справочник типов достижений
    get...
    set...
}

User.hbm.xml

<bag name="achievements" inverse="true" cascade="all,delete-orphan" order-by="CREATE_DATE">
    <key column="user_id"/>
    <one-to-many class="Achievement"/>
</bag>

Achievement.hbm.xml

<many-to-one name="user" column="user_id" class="User"/>
<many-to-one name="type" column="achievement_type_id" class="DicAchievementType"/>

Я правильно понимаю, что в топологии ваших серверов Nginx "смотрит в мир", а доступ к Tomcat-у(-ам) извне не предполагается? Т.е., стандартный подход: снаружи балансировщик, внутри сервера приложений на которые балансировщик перенаправляет запросы? В таких случаях Tomcat-ы должны быть закрыты полностью от любого доступа извне на уровне сети/прокси, т.е. они находятся в так называемой "демилитаризованной зоне" и не требуют защиты на уровне протокола обмена данными (HTTPS). Более того, обычно балансировщик при приеме соединения по HTTPS "раздевает" его, расшифровывает, и не имеет средств для повторного шифрования, да это и не нужно. Обычно, балансировщик, получивший данные по HTTPS-соединению передает их дальше на бакенды по протоколу AJP, который предназначен как раз для общения балансировщика с бакендами, т.к. по сравнению с обычным HTTP имеет средства для пинга доступности узлов на бакенде. Таким образом, в вашей конфигурации Nginx должны быть что-то вроде:

proxy_pass        http://127.0.0.1:8009; #8009 - default AJP port on Tomcat

Попытайтесь указать кодировку в url соединения в context.xml следующим образом:

url="jdbc:mysql://ip:3306/name?useUnicode=true&characterEncoding=UTF-8"

Насколько я помню, для 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