VoDA ,
Давайте спросим об этом соответствующий JSR :
JSRProfiles
The reach of the Java EE platform has become so broad that it has lost some of its original focus. To refocus the Java EE platform on particular classes of developers and applications, we propose the introduction of Java EE platform Profiles. Profiles will reference the Java EE platform, as defined by the JCP process, and may include a subset of Java EE platform technologies, additional JCP technologies not part of the base Java EE platform , or both. In addition to defining the base Java EE platform, this specification will define the rules for referencing Java EE platform technologies in Java EE Profiles.
This expert group will also define the first version of a Java EE Web Profile - a subset of the Java EE platform targeted at web application development. This profile will provide a more gentle introduction to the Java EE platform , providing only those technologies needed by most web application developers, without the enterprise technologies that sometimes confuse such developers .
Про ресурсы и производительность ни слова, что вполне логично. Дополнительные 50-100-200 метров памяти уже давно не вызывают каких-либо проблем.

VoDAJavaEE сервера в общем виде не обладают свойством "гибких политик репликации", т.к. как минимум несколько из них не обладают данным свойством
1) Никаких JSR и иных спецификаций по кластеризации серверов приложений не существует. А следовательно "гибкость" зависит исключительно от вендора. Поэтому утверждение "AppServer'a не обладают достаточной гибкостью в кластеризации" не имеет вообще никакого смысла.
2) Пример "гибкой" кластеризации (опять таки - я не знаю ваших критериев) - WebSphere. Если вам будет не лень, пробегитесь по вот этому документу - http://www.redbooks.ibm.com/redbooks/pdfs/sg246688.pdf. Если лень - то прочитайте хотя бы главу 2.4.1. Это достаточно гибко?

Йуный джавистЪ1)Логирование.
На нужные классы навешиваются соответствующие аннотации, во время сборки на них натравливается AspectJ. Не вижу, где здесь можно использовать Spring.Ну как бы спринг именно так и работает (вернее, это один из вариантов его работы).

Йуный джавистЪЯ не вижу недостатков в таком способе.Бывает. А я вот вижу в вашем подходе следующие недостатки:
1) Где параметры транзакции? Уровень изоляции, параметры присоединения/открытия (Requires, RequiredNew, Supported, Mandatory и т.д.)? Вы вообще про такие вещи слышали?
2) Как вложенные транзакции будут у вас работать?
3) Как мне быть, если я хочу откатывать транзакции только при определенных исключениях?
4) Runnable - громаднейший косяк. То есть вы заставляете код жестко подстравиться под вас - в классе может быть не более одного транзакционного метода. То есть пишу я значит сервис с 3-мя транзакционными методами, в Спринге мне для этого надо написать 1 класс, в вашем случае минимум 3. Ну круто, чо.
Теперь некоторое пояснение - декларативные транзакции на то и декларативные, что они вообще никак не проявляют себя в коде и не накладывают на него никаких ограничений. Spring нам такую возможность дает, ваш подход - заставляет разработчика подстраиваться под надуманное правило "implements Runnable", то есть ни о какой декларативности речи не идет в принципе.

Йуный джавистЪЯ не вижу недостатков в таком способе.Ок, не вопрос.

justforsqlruЭЭЭЭ это есть в спринге ?Ну как бы без этого в принципе нельзя говорить о транзакциях.

Йуный джавистЪ ,
С вашего позволения позволю себе продолжить разнос _кода_без_недостатков_:
5) А как мне параметры передать в транзакционный метод? У нормальных людей это выглядит вот так:


У вас же я должен сделать следующее:

То есть на каждый вызов сервиса нужен новый одноразовый инстанс этого сервиса. Круто.

6) А как бы мне вернуть результат вызванного транзакйионного метода? У нормальных людей это выяглдит вот так:

У вас это не выглядит никак, ибо это невозможно

Йуный джавистЪВ Java нормальные средства декомпозиции, а в Spring XML - кривые.Вам виднее

Йуный джавистЪЧтобы разбить большой xml файл на части, надо использовать import. Если в двух файлах, подтягиваемых импортом, есть бины с одинаковыми именами, то спринг не сообщит об ошибке, а молча использует то описание бина, которое встретится последним.Счастличой отладки. 1) Пишем xml-конфигурацию log4j
2) Пишем конфигурацию Hibernate
3) Пишем persistence.xml
4) Пишем определения сервлетов в web.xml
5) Пишем структуру приложения в application.xml
6) Пишем сборочный скрипт для Ant или Maven
Что объединяет все эти случаи? То, что на этапе компиляции мы не сможем отловить ошибки в xml-никах. Ай беда беда, это смахивает заговор прям
Рекомендации:
1) Боитесь описания контекста в XML - переходите на аннотации
2) http://en.wikipedia.org/wiki/Convention_over_configuration - это для общего развития, чтобы вы понимали откуда вообще к нам пришли эти дурацкие xml-ники, сулящие адский ад при дебаге.

Йуный джавистЪВ Java просто невозможна ситуация, когда, например, в классе определены 2 метода с одинаковыми именами, и используется только последний. Мы вносим изменения в первый, и не понимаем, почему эти изменения не действуют.Эммм, ну вы как бы в контексте спринга описываете только имена классов и зависимости. Методы в нем не описываются

Йуный джавистЪЕсли для описания конфигурации полноценный язык не нужен, то зачем тогда надо было делать Spring EL? Мне кажется, через пару лет разрешат вставлять в XML файлы куски кода на нормальных языках и конфигурировать бин с названием codeEvaluator, который наследует от AbstractCodeEvaluatorFactory, и у которого из коробки три реализации - JavaCodeEvaluatorFactory, JavaScriptCodeEvaluatorFactory и еще какой-нибудь GroovyCodeEvaluatorFactory.Все может быть

Йуный джавистЪВ нескольких мегабайтах библиотек содержатся тысячи багов и граблей (см пример выше).Голословщина.

авторВ моем коде Runnable - точный аналог
TransactionCallback, а WithTemplate - упрощенный аналог TransactionTemplate. Разумеется, бины не должны имплементить Runnable, так же как они не должны имплементить TransactionCallback.Ок, ответ принимается, вопрос снимается.

авторКстати, раз вы не уловили аналогии моего WithTransaction со спринговским TransactionTemplate, можно сделать вывод, что вы Spring сами не знаете. При этом позволяете себе хамитьИнтересный вывод. Напоминаю вам, что речь идет про декларативные транзакции . Вот вам пример, как это выглядит в спринге (один из 2х вариантов).

1. Интерфейс:



2. Реализация:



3. Спринг:



4. Вызов транзакционных методов:



Ну что, вы начинаете понимать, что такое декларативные транзакции ? Вы все еще убеждены, что я не знаю Spring?

grasoff.net http://static.springsource.org/spring/docs/2.5.x/reference/transaction.html Много раз натыкался на эту статью. все время распухала голова, уж очень там перегружено всяким низкоуровневым AOP-ом. В реальности, если наша цель только декларативные транзакции, то выбор обычно идет между либо связкой transactionManager/transactionInterceptor/proxy-бины (как в моем примере), либо аннотациями, прямой AOP нафиг не сдался.
Но эта статья очень хорошо раскрывает теоретические аспекты декларативных транзакций и преимуществ их применеия, а потому настоятельно рекомендуую ее к прочтению Йуный джавистЪ .

Йуный джавистЪВ чем именно я не разобрался? Разве то что я написал, неверно?Вы с чего взяли, что это ошибка или проблема? 1) Случай высосан из пальца. Именя бинов в большинстве случаев делают соответствуютщими имени класса, тут хрен ошибешься
2) Если даже такое и произошло, это очень скоро даст о себе знать ClassCastException и свалившимися тестами. Это вам не проблемы с многопоточностью, которые хрен выловишь, это элементарнейшая и простейшая ошибка, которая исправляется за минуту.
3) Эта фича полезна при тестировании и при развертывании приложения в разных окружениях. Вот у меня дефолтная конфигурация для WebSphere, а вот у меня импорт, который заменяет JNDI ресурсы на локальные, а вот у меня импорт, который позволит работать на WebLogic - например, подменяет TransactionManager.
Так что никакого криминала в этом "недостатке" нет, не выдумывайте.