Помимо EAR и EJB, что я получаю от сервера приложений Java EE, который я не получаю в контейнере сервлетов, таком как Tomcat?

когда мы отправились с целью Java EE 6 сертифицировать Apache Tomcat как Apache TomEE, вот некоторые из пробелов, которые нам пришлось заполнить, чтобы, наконец, передать Java EE 6 TCK.

не полный список, но некоторые моменты, которые могут быть не очевидны даже с существующими ответами.

Нет TransactionManager

управление транзакциями определенно требуется для любого сертифицированного сервера. В любом веб-компоненте (сервлет, фильтр, прослушиватель, JSF managed bean) вы должны иметь возможность получить UserTransaction вводится так:

• @Resource UserTransaction transaction;

вы должны иметь возможность использовать javax.transaction.UserTransaction для создания сделок. Все ресурсы, которые вы касаетесь в области этой транзакции, должны быть зарегистрированы в этой транзакции. Это включает, но не ограничивается следующим: объекты:

• javax.sql.DataSource
• javax.persistence.EntityManager
• javax.jms.ConnectionFactory
• javax.jms.QueueConnectionFactory
• javax.jms.TopicConnectionFactory
• javax.ejb.TimerService

например, если в сервлете вы запускаете транзакцию, то:

• обновить базу данных
• запустите сообщение JMS в тему или очередь
• создать таймер, чтобы сделать работу в какой-то более поздний момент

.. а потом одна из этих вещей не удается или вы просто решили назвать rollback() на UserTransaction, тогда все эти вещи будут отменены.

Нет Объединения Соединений

чтобы быть очень ясным, есть два вида объединения соединений:

• транзакционно осведомленный пул соединений
• не транзакционно известны пула подключений

спецификации Java EE строго не требуют пула соединений, однако если у вас есть пул соединений, он должен быть сделка, знали или вы потеряете управление транзакциями.

что это означает:

• все в одной транзакции должны иметь одинаковое соединение из пула
• соединение не должно быть возвращено в пул до завершения транзакции (фиксация или откат), независимо от того, вызвал ли кто-то close() или любой другой способ на DataSource.

общая библиотека, используемая в Tomcat для подключения объединение является общим-dbcp. Мы также хотели использовать это в TomEE, однако он не поддерживал пул соединений с транзакциями, поэтому мы фактически добавили эту функциональность в commons-dbcp (yay, Apache), и она существует с версии 1.4 commons-dbc.

обратите внимание, что добавление commons-dbcp в Tomcat все еще недостаточно для получения пула транзакционных соединений. Вам все еще нужен менеджер транзакций, и вам все еще нужен контейнер, чтобы сделать сантехнику регистрации соединений с TransactionManager via Synchronization объекты.

в Java EE 7 есть разговоры о добавлении стандартного способа шифрования паролей БД и упаковки их с приложением в защищенном файле или внешнем хранилище. Это будет еще одна функция, которую Tomcat не будет поддерживать.

Нет Интеграции Безопасности

WebServices security, JAX-RS SecurityContext, EJB security, JAAS login и JAAC-все концепции безопасности, которые по умолчанию не" подключены " в Tomcat, даже если вы индивидуально добавьте библиотеки, такие как CXF, OpenEJB и т. д.

все эти API, конечно, должны работать вместе на сервере Java EE. Было довольно много работы, которую мы должны были сделать, чтобы заставить все это сотрудничать и делать это поверх Tomcat Realm API, чтобы люди могли использовать все существующие Tomcat Realm реализации для управления их безопасностью "Java EE". Это действительно все еще Tomcat security, он просто очень хорошо интегрирован.

JPA Интеграция

Да, вы можете сбросить провайдера JPA в a .war файл и использовать его без помощи Tomcat. При таком подходе вы не получите:

• @PersistenceUnit EntityManagerFactory закачки/просмотра
• @PersistenceContext EntityManager закачки/просмотра
• An EntityManager подключен к пулу транзакционных соединений
• JTA-удалось EntityManager поддержка
• расширенные контексты персистентности

JTA-управляемый EntityManager в основном имею в виду это два объекта в одной транзакции, которые хотят использовать EntityManager оба увидят то же самое EntityManager и нет необходимости явно передавать EntityManager вокруг. Все это "прохождение" делается за вас контейнером.

как это достигается? Просто,EntityManager вы получили из контейнера-это подделка. Это обертка. Когда вы используете его, он выглядит в текущей транзакции для реального EntityManager и делегирует вызов EntityManager. В этом причина загадочного EntityManager.getDelegate() метод, поэтому пользователи могут получить реальные EntityManager если они хотят и используют любые нестандартные API. Делайте это с большой осторожностью, конечно, и никогда не держите ссылку на делегата EntityManager или у вас будет серьезная утечка памяти. Делегат EntityManager обычно будет сброшен, закрыт, очищен и отброшен, когда транзакция завершится. Если вы все еще держите ссылку, вы предотвратите сбор мусора этого EntityManager и, возможно, все данные его зацепки.

• всегда безопасно держать ссылку на EntityManager ты достал из контейнера
• его не безопасно держать ссылку на EntityManager.getDelegate()
• будьте очень осторожны, держа ссылкой на EntityManager вы создали себя через EntityManagerFactory -- вы на 100% отвечаете за его управление.

интеграция CDI

я не хочу упрощать CDI, но я считаю, что он слишком большой, и многие люди не принимают серьезный взгляд - это в списке " когда-нибудь "для многих людей :) Итак, вот только пара основных моментов, о которых, я думаю," веб-парень " хотел бы знать.

вы знаете все положить и получить вы делаете в типичном webapp? Вытаскивать вещи из HttpSession весь день? Используя String для ключевых и непрерывно литья объектов, которые вы получаете от HttpSession. Вероятно, у вас есть код утилиты go, чтобы сделать это за вас.

CDI также имеет этот код утилиты, он называется @SessionScoped. Любой объект с аннотацией @SessionScoped попадает и отслеживается в HttpSession для вас. Вы просто запрашиваете объект, который будет введен в ваш сервлет через @Inject FooObject и контейнер CDI будет отслеживать" реальный " экземпляр FooObject таким же образом, как я описал транзакционное отслеживание EntitityManager. Абракадабра, теперь вы можете удалить кучу кода :)

делать какие-либо getAttribute и setAttribute on HttpServletRequest? Ну, вы можете удалить это тоже с @RequestScoped в то же путь.

и конечно @ApplicationScoped ликвидировать getAttribute и setAttribute звонки, которые вы могли бы делать на ServletContext

чтобы сделать вещи еще круче, любой отслеживаемый объект может реализовать @PostConstruct, который вызывается, когда компонент создается и @PreDestroy метод, который будет уведомлен, когда упомянутая "область" будет завершена (сеанс завершен, запрос закончен, приложение завершает работу).

CDI может сделать намного больше, но этого достаточно, чтобы сделать любого хотите переписать старое приложение.

некоторые придирчивые вещи

есть некоторые вещи, добавленные в Java EE 6, которые находятся в рулевой рубке Tomcats, которые не были добавлены. Они не требуют больших объяснений, но учитывают большой кусок "заполнения пробелов".

• поддержка @DataSourceDefinition
• Поддержка глобального JNDI (java:global, java:app, java:module)
• укол перечисления через @Resource MyEnum myEnum и
• инъекции класса via @Resource Class myPluggableClass и
• поддержка @Resource(lookup="foo")

незначительные моменты, но это может быть невероятно полезно определить DataSource в приложении портативным способом, доля записей JNDI между webapps, и имеют простую власть сказать: "посмотрите эту вещь и ввести его"

вывод

как уже упоминалось, не полный список. Нет упоминания о EJB, JMS, JAX-RS, JAX-WS, JSF, проверке бобов и других полезных вещах. Но хоть какое-то представление о вещах часто упускается из виду, когда люди говорят о том, что Tomcat-это и не.

также имейте в виду, что то, что вы могли бы подумать как "Java EE", может не соответствовать фактическому определению. С веб-профилем Java EE уменьшилась. Это было сознательно для адреса "Java EE слишком тяжелый, и мне не нужно все это".

если вы вырезали EJB из веб-профиля, вот что у вас осталось:

• Java-Сервлетов
• Java ServerPages (JSP)
• Java ServerFaces (JSF)
• Java Transaction API (JTA)
• Java Persistence API (JPA)
• контексты Java и инъекция зависимостей (CDI)
• Проверка Зернах

это довольно чертовски полезный стек.

Если вас просят перейти на коммерческий сервер J2EE, причины могут не иметь ничего общего со стеком J2EE, но с нетехническими соображениями.

одна вещь, которую вы получаете с коммерческим предложением J2EE, которое вы не получаете с Tomcat, - это техническая поддержка.

Это не может быть рассмотрением для вас, в зависимости от уровней обслуживания, которые должны соответствовать вашим веб-приложениям. Могут ли ваши приложения быть вниз, пока вы пытаетесь выяснить проблему с Tomcat, или это серьезная проблема?

стоимость не обязательно является недостатком, так как есть несколько бесплатных серверов J2EE, например JBoss и Glassfish.

ваш вопрос предполагает, что (J2EE = Servlet + EJB + EAR), и поэтому нет смысла использовать что-либо большее, чем контейнер сервлета, если вы не используете EJB или EAR. Это просто не так, J2EE включает в себя гораздо больше, чем это. Примеры включают:

• JTA - Java transaction API
• JPA - Java persistence API
• JMS-Java спецификация обмена сообщениями
• JSF-технология построения пользовательских интерфейсов из компонентов

Ура, Донал!--1-->

по правде говоря, с огромным массивом пакетов и библиотек, доступных, мало контейнер EJB обеспечивает, что не может быть добавлен в современный контейнер сервлетов (ala Tomcat). Итак, если вы когда-либо хотели какую-либо из этих функций, вы можете получить их "ALA carte", так сказать, со стоимостью процесса интеграции этой функции в ваше приложение.

Если вы сейчас не" пропускаете " ни одну из этих функций, то с практической точки зрения они вам, вероятно, не нужны.

Что все сказанное, современные контейнеры EJB действительно славны, и приходят со всеми из тех обслуживаний пре-интегрированных, делающ их, несколько, легкий для использования если вы всегда хотите их. Иногда наличие функции рядом и удобно достаточно, чтобы заставить кого-то исследовать ее потенциал в своем приложении, а не видеть процесс интеграции функции в качестве препятствия для принятия.

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

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

Как правило, когда речь идет о запуске Tomcat против контейнера EJB, вопрос в том, почему бы не использовать его? Говоря конкретно о Glassfish, я нахожу его более простым в использовании чем Tomcat, и основное различие заключается в том, что он может иметь умеренно больший объем памяти (особенно для небольшого приложения), чем Tomcat, но в большом приложении вы даже не заметите этого. Для меня хит-памяти не имеет большого значения, для других это может быть проблемой.

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