Когда отбрасывать контейнер Java EE (т.е. JBoss) для прямого Tomcat

Question

В настоящее время мы развертываем на JBoss 4.2, так как это сервер приложений, развернутый в нашем кластере. В настоящее время приложение использует только обработку пула соединений JBoss через JNDI и встроенный в JBossWeb Tomcat и несколько клапанов JBoss Tomcat (в частности, RewriteValve, ничего особенного сделать самостоятельно).

JBoss мне кажется излишним, стоит ли переходить на прямой Tomcat или есть какие-то преимущества в том, чтобы остаться с JBoss? Tomcat лучше интегрируется с Eclipse?

Answer 1

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

Если все, что вы используете из JBoss, это JMS или JNDI или что-то еще, что легко встраивается как отдельный сторонний компонент в Tomcat, то непременно отбросьте JBoss и перейдите просто к встроенному Tomcat.

Когда стоит придерживаться JBoss? Использование JBoss делает вашу жизнь намного проще, поэтому дополнительная работа по обновлению JBoss стоит усилий. Это верно для многих людей. Похоже, что это не так в вашем случае.

Что касается лучшей интеграции с Eclipse, я ожидаю, что оба будут хорошо интегрироваться с Eclipse. Я использую MyEclipse, который поддерживает JBoss и Tomcat. Так что это может зависеть от того, какую версию Eclipse и какие плагины вы используете.

Answer 2

Я бы пошел с Tomcat или Jetty, если вам нужен только JMS, и если вам не нужен поставщик транзакций, управляемый сервером приложений, для транзакций, которые охватывают больше, чем просто JDBC (например, транзакция, охватывающая JMS + JDBC) .

Хотя вы можете использовать JTA и JMS вне сервера приложений, такого как JBoss, у меня был очень смешанный опыт, когда JTA охватывал JMS и JDBC под Tomcat. Возможно, это был ранний выпуск ActiveMQ, но он действительно съел несколько месяцев в очень важном проекте. Что-то нужно сказать об инфраструктуре, которую обеспечивает сервер Java EE, такой как JBoss, особенно. когда вам нужен JTA с XADataSources. Попытка воссоздать это с автономными компонентами сбивает с толку.

Кстати, я бы предпочел Jetty, а не Tomcat, если у вас есть выбор.

Что касается интеграции Tomcat и Eclipse, здесь есть много вариантов. Я использую (несколько нестандартный) плагин вызова Sysdeo Tomcat Plugin для Eclipse. Стандартный подход - использовать что-то вроде WTP. Я использую плагин Sysdeo Tomcat, потому что он, кажется, имеет самые низкие издержки. Другой вариант - просто использовать плагин Jetty Eclipse - опять же, я обнаружил, что Jetty предпочтительнее, чем Tomcat, практически всеми возможными способами.

Answer 3

Вы можете попробовать это: http://www.atomikos.com/Publications/J2eeWithoutApplicationServer - в сочетании с облегченным веб-контейнером и калиткой, если вам нужен веб-уровень.

Комбинация из них даст вам беспрецедентную производительность в Java / Java EE.

НТН Guy

Answer 4

В зависимости от того, что именно вы пытаетесь сделать, вы можете рассмотреть Jetty.

Answer 5

Какая интеграция с Eclipse вам нужна? Я считаю, что есть плагины, которые будут выполнять какую-то интеграцию (например, плагин Sysdeo Eclipse Tomcat Launcher ), но я всегда находил, что проще всего просто запустить Tomcat в режиме отладки, если мне нужно - и это было довольно легко.

Что касается того, стоит ли придерживаться JBoss: если вам не нужны функциональные возможности, это, вероятно, того не стоит. Есть много способов сделать пул соединений в Tomcat, в зависимости от того, что еще вы используете. (Например, если вы используете Hibernate и Spring, различные пулы соединений хорошо работают в этом.)

Tomcat в любом случае предоставляет собственную реализацию JNDI - согласно документация Tomcat 5.5 .

Многое можно сказать о наличии достаточно «скудного и среднего» стека - не с точки зрения производительности, а с точки зрения понимания того, что происходит внутри приложения, и упрощения развертывания.