Как веб-сервер / контейнер относится к POJO по отношению к другим классам, таким как EJB и Entities?

Question

Я пытаюсь использовать обычные старые Java-объекты (POJO) и обычные файлы классов там, где это необходимо, и использовать EJB-компоненты только тогда, когда мне нужна добавляемая ими функциональность, такая как асинхронные вызовы, объединение в пул и т. Д. Мне интересно, каксервер обрабатывает это поведение после развертывания проекта на сервере.Поскольку он не управляется контейнером, нужно ли создавать новый экземпляр для каждого пула сеансов без сохранения состояния, который может вызывать один из его методов?Как такие вещи, как статические методы или состояние, влияют на эту модель.

Редактировать:

1) Я могу уточнить больше.Смысл Java EE в том, что вы аннотируете POJO с помощью @stateless и т. Д., Чтобы контейнер мог управлять им.Вам не нужно объявлять новый экземпляр bean-компонента без состояния, который вы просто внедряете и можете делать вызовы этого типа.

2) В большинстве учебников и книг по Java EE никогда не упоминаются аннотированные классы как часть вашей бизнес-логики.Это никогда не воспитывалось.Мне кажется странным, если вы можете использовать их в проектах Java EE для своей бизнес-логики, и она может быть развернута на сервере.Если вам не нужен пул или асинхронный доступ - вещи, которыми контейнер помогает управлять через EJB, вы можете использовать эти обычные POJO в своем проекте Java EE.

3), что приводит меня к моему вопросу, которыйКак правильно включить в проект?Я помещаю их в проект EJB, который связан с EAR, или они должны идти в EAR?или динамический веб-проект.Там почти нет упоминания или инструкции по правильному использованию обычных объектов, как это.Когда он скомпилирован в WAR-файл для развертывания, возникают ли какие-либо проблемы на сервере?Разве это не ожидание должным образом аннотированных EJB, сервлетов или JSP?

Answer 1

Не влияет на это вообще.Классы - это классы, объекты - это объекты.Они не управляются, им не мешают, с ними ничего не происходит.Они не особенные, ни в коем случае.

Статические синглоны - это статические синглоны, Java - это java.

Все, что вам нужно знать, это макет загрузчика классов вашего контейнера и его связь.к вашим развернутым приложениям и ресурсам.(Например, классы в одном приложении не могут видеть классы в другом приложении.) В большинстве случаев это не так важно.Иногда все становится сложнее.

Но по большей части это просто Java.

Дополнения:

Лучший способ взглянуть на этопросто сгруппируйте ваши классы по блокам локальности.

Давайте возьмем простое веб-приложение, использующее EJB.

Веб-приложение развернуто в артефакте WAR, а EJB можно развертывать отдельно.как отдельные EJB в контейнере или, что более вероятно, в EAR.Когда вы упаковываете свое приложение в EAR, вы, вероятно, также объедините WAR в EAR.Итак, в конце EAR содержит вашу WAR и ваши EJB.

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

1. Классы, относящиеся исключительно к EJB (например, Session Beans).

2. Классы, относящиеся исключительно к WAR (например,как класс сервлета).

3. Классы, относящиеся к обоим (возможно, к базе данных).

Итак, простой способ упаковкиони находятся в трех файлах фляги.JAR-файл для вашей WAR (на самом деле это WAR-файл с классами в WEB-INF / classes), JAR-файл для ваших EJB-компонентов и JAR-файл для 3-го типа, мы будем называть это библиотекой.

С точки зрения зависимости сборки сборка WAR зависит от lib, а сборка EJB зависит от lib.Но ни WAR, ни EJB не зависят друг от друга, поскольку они ничего не делят напрямую, только косвенно через 3-й библиотечный jar.Библиотека jar является автономной, поскольку она не зависит ни от WAR, ни от EJB.Обратите внимание, что ваши интерфейсные классы EJB Session Bean будут входить в библиотечный jar (поскольку оба уровня полагаются на них).

На вашем ухе вы просто связываете библиотечный jar, WAR и EJB jar вместе скаталог META-INF и файл application.xml.WAR имеет свою собственную структуру, с WEB-INF и всеми, у EJB jar есть META-INF и ejb-jar.xml.Но следует отметить, что lib.jar НЕ находится в каталоге WEB-INF / lib, он находится в комплекте EAR и, таким образом, совместно используется как EJB, так и WAR, используя chicanery загрузчика классов, за который отвечает контейнер.

Это важно отметить.Например, если у вас есть, скажем, простой статический синглтон в вашем lib jar, то ОБА и WAR, и EJB будут использовать этот синглтон, так как они все являются частью одного загрузчика классов.Чтобы использовать этот синглтон, это просто обычная Java.Ничего особенного там нет.

Если бы EJB и WAR были развернуты по отдельности, им КАЖДАЯ потребовалась бы собственная копия lib.jar, а в случае Singleton они НЕ поделились бы ею, поскольку каждый модульесть собственный загрузчик классов.

Таким образом, если исключить некоторые реальные потребности записи, проще объединить все в EAR и рассматривать как EJB-уровень, так и WAR-уровень как единое интегрированное приложение.

Дополнения 2:

Люди не слишком много говорят об использовании классов в разработке Java EE, потому что им не о чем говорить, они просто используют их, как в любой Java-программе.Ты слишком обдумал это здесь.

Идиома 3 jar: war, ejb, lib - это та, которую я использовал годами, потому что она разделяет 3 проблемы и ограничивает зависимости.Клиент -> lib -> EJB.Это также упрощает сборку, поскольку клиентам обычно нужны только lib jar и java.В среде IDE Netbeans этим тривиально управлять.С незначительной работой это просто в других IDE или даже в ant / maven.Это не большое бремя, но содержит три части относительно чистыми.

Зависимость и управление Jar - это кошмар любого крупного Java-проекта, и особенно в EJB, когда вы имеете дело с различными развертываемыми артефактами.Все, что может помочь смягчить, что является победой, в моей книге, и по правде говоря, чистый, автономный lib jar очень помогает, особенно в том, что вам нужно интегрировать и использовать эту lib с другим кодом.Например, если вы позже напишите внешний клиент с графическим интерфейсом, используя удаленные EJB-компоненты или даже веб-службы, lib jar будет единственной зависимостью, которую имеет клиент.Преимущества этого jar намного перевешивают незначительную боль, которая требуется для настройки библиотеки такого типа.

В конце концов, lib jar - это просто jar, как и любой другой jar, который вы хотите использовать в своем приложении (как регистрация или любые другие популярные банки от третьих лиц).