justforsqlruМожете пояснить как ?1) Открыть гугл, вбить туда "Inversion of Control Service Locator", вкурить
2) Открыть гугл, вбить туда "EJB 2.1 example", вкурить, найти пример использования паттерна Service Locator.

Вторая строка это классический сервис локатор.

justforsqlruПокурил посмотрел инициализацию полей через Service Location ( банальная фактори )Типичное заблуждение. Factory это creational pattern, он создает объекты. Service Locator в общем случае возвращает объект из некоего контекста. Он его не создает, и это не creational pattern.

justforsqlruа в 3-м ejb нет jndi ?Разве я где-то это сказал?

VoDAк вот этому смешному коду применения IoC - код будет забавен что на Spring что на EJB.То есть вы не смогли осознать, что в приложении не все происходит через DI, особенно в сторонних библиотеках? Мой пример был призван продемонстрировать именно это.

VoDAвы показали попытку создать spring bean через new. я провел доступную аналогию.Ничего подобного. Если вы внимательно и вдумчиво посмотрите на мой пример - 11757590 , то вы увидите что у меня есть два класса и только один бин, и никакие спринговые бины через new я не создавал.

VoDAкластера на JavaEE строятся быстрее, но не такие гибкие.
кластера через terracotta (к примеру)подобные реализации возможно будут строиться дольше, но обладать более гибкими политиками репликации, а значит возможность масштабироваться у них выше.0_о Тааак, вижу тотальное непонимание того, что подразумевается под термином "кластер" и какие типы кластеров бывают. Вы опять сравниваете несравнимое.
То, что вы называете "кластера на JavaEE" (я так понимаю, что это кластера из AppServer'ов) решают широкий спектр задач - от распределения нагрузки на веб-сервер, до кэширования сесссий. Кластера Terracota решают ограниченный спектр задач, как-то кеширование веб-сессий и хранения большого объема данных где-то вне AppServer'а.
Если у вас стоит сервер приложений и на него вдруг навалилось 100500 миллионов пользователей, то никакая терракота вас не спасет, поможет только кластер на уровне web-сервера с лоад-балансером.
Более того, некоторые фичи терракоты, например WebSessions, вообще не имеют смысла без вышележащего кластера на основе AppServer/WebServer, ибо какой смысл кешировать сессию, если у нее только один "потребитель"?
То есть вы опять сравниваете несравнимые вещи.
И вот вопрос еще - а в чем проявляется "негибкость политик репликации" у кластеров на основе AppServer'ов?

VoDAв подавляющем большинстве случаем именно Spring IoC определяет какие именно функции из ареала Spring * запускать. Сами же подсистемы Spring * уже поднимают и конфигурируют внешние подсистемы. Таким образом если приложению нужен Spring JMS реализованные через внешнюю зависимость, то Spring JMS и внешняя зависимость будут загружены. Если же приложению Spring JMS и внешняя зависимость не нужны, при учете того, что Spring используется адекватно(*), то ни сама прослойка Spring JMS ни внешняя зависимость не будут загружены.Это звучит уже более вменяемо, значит не зря я тут время трачу Хотя глупости все еще присутствуют, например фраза:
авторпри учете того, что Spring используется адекватно(*), то ни сама прослойка Spring JMS ни внешняя зависимость не будут загружены...лишена смысла, ибо если приложению не нужен JMS, то он не будет загружен (приложением) хоть там есть спринг, хоть нет.
Я просто вам напомню ваши слова (только вот почему вы называете это "придиркой", я не понимаю - скажи вы такое на собеседовании, вам бы в лицо рассмеялись).
11753879 :
VoDAСпринг заметно быстрее поднимает приложение просто потому, что грузит ровно то, что требуется и не более.Не спринг определяет что грузить, а что нет, а разработчик.
11757407 :
VoDAjar ники конечно maven закидывает. только если конфигурация компонента не прописана в applicationContext, то и компонент не грузится самим Спрингом - к нему просто нет обращений.Спринг не грузит никакие компоненты, компоненты загружаются класслоадерами. Что грузить, а что нет, определяется внутренними зависимостями приложения, а не контекстом.
авторСпринг (из applicationContext) вытаскивает знания что нужно грузить.Ну тут без комментариев - бред сивой кобылы.

VoDAм... ок. ваше мнение Spring не контейнер.
Инженеры Interface21 (еще до смены имени на SpringSources) называли и продолжают именовать Spring именно контейнером. По крайней мере Spring IoC container. Я придерживаюсь официальной политики.Вот ваша фраза:
VoDA2) Определяемся с реализацией JavaEE сервера если выбран JavaEE или реализацией web-container если в качестве основного контейнера выбран SpringВы можете мне пояснить, что значит выражение "основной контейнер"? Какие еще "основные контейнеры" вы знаете?

VoDAПомня, что Spring IoC без остальных технологий Spring * - это бесполезная часть.Очень смело. На самом деле Spring IoC это основная и самая главная часть. Использовать или нет все остальное - зависит от требований. Spring MVC это веб-фреймворк, он к разговору вообще отношения не имеет. У меня может быть весь каркас приложения собран на основе Спринга, а веб реализован на чем-то отличном от SpringMVC, нисколько не уменьшит ценность Spring IoC. Далее, Spring WebService - имеет крайне узкую область применимости. Во-первых, он поддерживает только bottom-up подход, во-вторых его использование на серверах приложений, которые уже имеют свою реализацию движка веб-сервисов, лишено смысла. Но на Томкате пойдет на ура, факт. Далее, Spring Timers - ну я вообще не понимаю, зачем вы его привели. А если у меня нет в приложении никаких таймеров, что Spring IoC становится бесполезным?
Вывод: Spring IoC это самая важная и самая главная часть из всего Spring'a. Все остальное имеет гораздо более узкую область применения, а потому второстепенно.

Йуный джавистЪВторой вариант написан в DI стиле, первый в обычном. Второй сложнее, но более гибкий. DI делает код более слабо связанным, и его легче тестировать - например первую реализацию функции doStuff невозможно протестировать, а вторую можно - надо передать ей mock, реализующий интерфейс ResultReporter. Наверное, DI это полезный подход, хотя, как мне кажется, в Java мире им злоупотребляют.Абсолютно неверно. В вашем примере есть такие понятия, как интерфейс и реализации, но нет DI в принципе.

Йуный джавистЪЕсли мы написали какое-то количество классов в стиле DIКласс не может быть написан "в стиле DI". DI всегда вынесен за пределы класс, а потому в самом классе не виден. Смотря на класс вы никак не можете знать, используется ли реально DI или нет.

Йуный джавистЪто чтобы получить работающую программу, необходимо
1)Создать экземпляры всех классов.
2)Связать их друг с другом, примерно так же, как doStuff связывается с ResultReporter.
Штука, которая это делает, называется IoC контейнером.Первое неверно, второе близко к истине.

Йуный джавистЪДальше встает вопрос, нужна ли какая-то специальная библиотека, которая служила бы IoC контейнером?
Мое мнение, что нет.
Самодельный контейнер выглядит примерно так:То, что вы написали назвать контейнером можно с огромной натяжкой.
Йуный джавистЪ1)Соответствие типов проверяется java-компилятором.И? В чем преимущество то заключается?
Йуный джавистЪ2)При создании классов у нас есть целиком язык Java, а не ограниченный xml-язык спринг конфигураций.В конфигурации спринга мы определяем только зависимотси, то есть что куда вставить. Мы никак не ограничены по части Java-кода.
Йуный джавистЪ3)Не надо тянуть большие дополнительные библиотеки.В чем заключается проблем подтянуть несколько мегабайт библиотек? Мы же не в 80-е годы живем.

Йуный джавистЪВ Spring есть Spring AOP, с помощью которого можно разом запроксировать много объектов. Но я не знаю, как это можно было бы применитьТранзакции, безопасность, логирование. Почитайте про AOP в целом, поймете.

Йуный джавистЪВ документации говорится, что Spring AOP используется в первую очередь для транзакций, но мне это кажется надуманным - все можно сделать проще.Что такое декларативное управление транзакциями знаете? Можете предлолжить что-то "проще"?

Кстати вот интересная статейка - http://zeroturnaround.com/java-ee-productivity-report-2011/ (единственное, меня немного напрягло, что там Hibernate засунут в категорию веб-фреймворков).
Касательно популярности Tomcat/неTomcat полностью коррелирует с моей таблицей, сделанной по сайту hh.ru.

Pavel KurakinМне не понятна выделенная фраза, Вы знаете какое то тайное понятие Java контейнеров не иначе. Вы абсолютно правы в том что Spring это не контейнер в понятиях Java контейнеров, но само упоминание именно понятия контейнера в Java не понимаю зачем здесь.Ну да, фраза некорректная. Я здесь имел ввиду то, что есть контейнеры "инфраструктурные" - Tomcat (контейнер сервлетов), EJB-контейнер в AppServer'ах и т.д.. Spring же - это просто одна из реализаций DI, выполненная в виде контейнера объектов, она работает на другом уровне - уровне приложения. К чему я все это писал? Пока не знаю, надо дождаться комментариев по фразе:
VoDA2) Определяемся с реализацией JavaEE сервера если выбран JavaEE или реализацией web-container если в качестве основного контейнера выбран Spring

VoDAпоразите меня - вы в своих JavaEE приложениях EJB связываете без применения EJB DI?Это вы на основании чего сделали такой вывод? Перечитайте то, что я написал:
svenomТо есть вы не смогли осознать, что в приложении не все происходит через DI, особенно в сторонних библиотеках ?Напомню, что это относится к вашим интересным утверждениям типа "Spring решает, что грузить, а что нет".

VoDAок, тогда пример не имеет смысла в данном контексте. я рассказывал про spring beans и работу согласно спеке Спринга.Пример преследует лишь одну цель - опровергунть ваши некорректные утверждения о том, что спринг как-то влияет на загрузку классов и библиотек.

VoDAterracotta это инфраструктура через которую можно кэшировать как веб-сессии, так и любые другие сессионные или не сессионные данные.Да.

VoDAа вы считаете, что web-server с лоад-балансером эта фича которую только AppServer-а умеют делать? такое даже на PHP можно реализовать без привлечения какой либо javaДа, можно. Вопрос вот в чем - какой смысл использовать Terracota WebSessions, если у нас только один web-сервер? Этот пример призван показать, что кластеризация на уровне серверов приложений решает задачи, отличные от тех, которые решает та же Terracota.

VoDAТот же JBoss, который полноценный JavaEE compatible server, довольно интересно реплицирует web-sessions. Репликация идет все-со-всеми. Как результат при интенсивной работе не рекомендуется больше 4-х нод. Выше падает производительность из-за высоких затрат на репликацию между нодами кластера. В качестве рекомендаций были либо использовать специальный "плагин" который реализует репликацию внутри группы, и сразу предупреждение о слабой протестированности оного. Либо предложение деления всего кластера на независимые группы и управление балансировщиком, чтобы пользователя всегда направляло на определенную группу (пока жива сессия).
Первое - совсем странно для продакшена, второе проще сделать самостоятельно ;)Ну ок, так вы тогда и говорите, что "JBoss имеет негибкие политики репликации", а не обобщайте это на все JavaEE сервера.