no56892,

Я уже десяток раз объяснял, вы бы хоть поиском посмотрели.
Вариантов несколько.

- Самый правильный это динамически управлять Fetch для каждого конкретного случая, чтобы загружать только те ассоциации, которые вам нужны в конкретном сценарии.
Для этого есть FetchMode в Criteria API, fetch в HQL и теперь даже Fetch Profiles, ещё не пользовал, но, похоже, очень полезная штука.

- Вариант попроще, держать сессию открытой, расширяя область действия транзакции и сессии. Называется Open Session In View. Имеет ряд недостатков.

- Ну, и самый корявый вариант в лоб, эдакий FetchMode для бедных - насильно прогрузить зависимости, например, через HibernateUtils, но до того как закроется сессия.

no56892Даже если сделать "...join fetch objects...", то при обращении к ним через getParent()/getChilds() вылетает LazyInitializationException. Как это решить?
Интересно, а что вас удивляет, то что fetch objects по какой-то странной причине выбирает только objects, но не выбирает другие зависимости??
Кстати, а getParent() по умолчанию не должен быть ленивым, это же обычное свойство. Его нужно обязательно проксировать для ленивости.

no56892Есть класс:
Ещё хочется отметить что такой банальный способ хранения деревьев в реляционной БД далеко не самый удобный. Есть другие способы оптимизированные под разные задачи.

no56892,

Тогда есть такие варианты.
- Написать HQL с fetch до определенного уровня. Для глубокого дерева будет уродливо.
- Инициализировать рекурсивно в коде. Правда, в этом случае будет много запросов, а не толстый JOIN
- Выгрести все нужные ноды с fetch на детей, а потом уже построить дерево по выборке.
- Но! По-моему именно здесь должен подойти как нельзя кстати Fetch Profile. Если вы утверждаете что FetchType.EAGER решает проблему (точно ли?), то можно его активировать для нужной сессии перед выборкой.