LINUX.ORG.RU

Вышел релиз фреймворка Spring 3.0

 ,


0

0

Основновые нововведения:

  • Spring expression language (SpEL): входящий в ядро парсер выражений, используемых в определениях бинов, позволяющий обращаться как к значениям вложенных бинов, так и к структурам окружения (таким, как значения системных свойств (property) через общепринятый синтаксис #{…} .
  • Расширена поддержка для компонентов, основанных на аннотациях: добавлены классы конфигурирования и аннотированые фабричные методы (по образу и подобию Spring JavaConfig). Теперь Spring позволяет осуществлять внедрение конфигурации через выражение @Value раскрывающееся через вычисляемое в рантайм #{…} или статическое ${…} выражение.
  • Выразительная модель включения типов позволяет создавать мета-аннотации для установки пользовательским типам области видимости и других характеристик. Скажем, пользовательская аннотация @MyService включает @Service, @Scope(«request») и @Transactional(readOnly=true) сразу.
  • Стандартизированное внедерение зависимостей. Spring 3.0 полностью поддерживает спецификацию JSR-330 на внедрение зависимостей - внедрение через аннотации @Inject с соответствующими моделями квалификаторов и поставщиков, - как альтернативу собственной модели внедрений через @Autowired и т.п.
  • Декларативная модель проверки на основе аннотаций-ограничений: настройка в стиле Spring поставщика JSR-303 Bean Validation (такого же как Hibernate Validator 4.0). Включает возможность проверки через аннотации в Spring MVC и предоставляет единый способ для определения ограничений на биндинг к Spring'у.
  • Улучшен биндинг и форматирование через аннотации: добавлены Converter и Formatter SPI как альтернатива стандартному PropertyEditor. Форматированием можно управлять аннотациями в стиле проверок JSR-303, к примеру используя @DateTimeFormat. Обратите внимание на новое пространство имен в Spring MVC для настройки форматирования и проверок.
  • Современная поддержка REST средствами самого Spring MVC - отображение адресов запросов в стиле REST, получение значений URI через параметр @PathVariable и подбор решения в зависимости от содержимого переговоров. Поддержка REST на стороне клиента возможна с помощью класса RestTemplate.
  • Встроенная богатая поддрежка Portlet 2.0: Spring MVC полностью поддерживает окружение, события и схему запроса ресурсов Portlet 2.0. Включая специальные возможности отображения для типовых характеристик запроса портлетов: @ActionMapping, @RenderMapping, @ResourceMapping, @EventMapping.
  • Отображение в Object/XML (OXM) ранее известное как часть Spring Web Services теперь стало частью ядра. Искаропки поддерживаются маршаллинг и анмаршаллинг JAXB 2, Castor и т.п. Возможна итеграция с XML в Spring MVC и Spring JMS.
  • Возможности шедулинга следующего поколения: механизмы TaskScheduler и Trigger с поддержкой cron'а. Spring 3.0 идет с пространстовм имен для управления задачами и поддерживает аннотации @Async и @Scheduled, которые могут быть выполенны через пул «родных» или управляемых сервером нитей .

Помимо этих основных изменений есть сотни улучшений в мелочах, которые вы, вероятно, оцените, когад будете апгрейдиться с Spring 2.5. Смотрите ченджлог и явадоки.

По части системных требований Spring 3.0 укладывается в широкий диапазон окружений. Два ключевых требования - поддержка Java SE 5 и Servlet 2.4 (и выше). Подйдут Tomcat 5.x и 6.x, хотя сохранена совместимость с WebSphere 6.1 и WebLogic 9.2 (которые формально всё еще основаны на J2EE 1.4). В тоже время мы уже поддерживаем GlassFish v3, адаптируя Spring к API Java EE 6.

Короче, Spring 3 предоставляет новые возможности компонентной модели и такие стандарты, как внедрения SR-330 и проверки JSR-303 для стабильного производственного окружения без необходимости апгрейдить сервера. Всё что нужно - обновить библиотеки вашего приложения до Spring 3.0.

>>> Подробности

★★★★★

Проверено: maxcom ()
Последнее исправление: maxcom (всего исправлений: 1)

Ответ на: комментарий от keeper-andrew

re: Спринг знает и умеет определять что создать первым а что потом...

> Чушь полная. Спринг знает и умеет определять что создать первым а что потом... А уже если ты попутал с циклическими ссылками то ты ССЗБ. Более того

Таки умеет? Удивительно.
ОК, допустим я не знаю спринг :) Не соблаговолит ли уважаемый человек с 3мя годами опыта в нем, глянуть на вот это:

---
<?xml version=«1.0» encoding=«UTF-8»?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd"
default-lazy-init=«true»>

<bean id=«c1» class=«C»>
<constructor-arg ref=«c2»/>
</bean>
<bean id=«c2» class=«C»>
<property name=«other» ref=«c1»/>
</bean>
</beans>

---
public class C {
public C(C other) {}
public C() {}
public void setOther(C other) {}
}
---
ApplicationContext context = new ClassPathXmlApplicationContext(«explosion.xml»);
context.getBean(«c1»);
---

У меня оно пишет на Spring 3.0.0 что «Requested bean is currently in creation».
Но весело работает, если сначала дергаю c2:

ApplicationContext context = new ClassPathXmlApplicationContext(«explosion.xml»);
context.getBean(«c2»); // вот оно, лекарство
context.getBean(«c1»);


аналогов aop:proxy ни в одном контейнере не существует! Благодаря чему в том же самом JSF многие вещи делаются через Ж. и все бины или искуственно держатся


Я не знаю, что за изврат такой этот aop:proxy и каким вообще боком тут AOP. В данном случае Spring не умеет делаеть элементарные вещи. Задача на автоматическое определение правильной последовательности инициализации решается даже школьниками без проблем, это не rocket science.

в сессии или постоянно висят в сессии. Спринг умеет проверять что required а что нет. так что сеттер не пропустишь. Подробности - кури мануалы.


Я не желаю писать в конфигах «required». Контракт кода должен быть в коде, а не в каком-то конфиге, что служит для связки компонентов. Так что пусть мануалы к этой убогой кривоте курят другие.

rtvd ★★★★★
()
Ответ на: комментарий от rtvd

> А что до любителей спринга, не знающих даже сколько бит в байте...

есть у меня одна альфочка... попробуйте угадать, сколько там бит в байте?)

anonymous
()

>Таки умеет? Удивительно.

ОК, допустим я не знаю спринг :) Не соблаговолит ли уважаемый человек с 3мя годами опыта в нем, глянуть на вот это:

Быдлокодерство. Но для даунов повторюсь:

А уже если ты попутал с циклическими ссылками то ты ССЗБ.

Я не знаю, что за изврат такой этот aop:proxy и каким вообще боком тут AOP. В данном случае Spring не умеет делаеть элементарные вещи. Задача на автоматическое определение правильной последовательности инициализации решается даже школьниками без проблем, это не rocket science.

Ликбез в соседней палате. Элементарные вещи спринг делает по всему миру милионы раз в сутки. Но найдется десяток человек с особо ровными руками для которых использовать спринг просто не судьба потому что даже элементарные вещи у них не работают.

Я не желаю писать в конфигах «required». Контракт кода должен быть в коде, а не в каком-то конфиге, что служит для связки компонентов. Так что пусть мануалы к этой убогой кривоте курят другие.

Ладно так уж и быть. контракт в коде: Устраивает?

+implements InitializingBean

@Override

public void afterPropertiesSet() throws Exception {

Assert.notNull(getPasswordPolicy(), «passwordPolicy must be specified»);

}

keeper-andrew
()
Ответ на: комментарий от KRoN73

Да, мне тоже интересно, что человек ответит :)


Молчит цуко! :)

vada ★★★★★
()

Я не желаю писать в конфигах «required». Контракт кода должен быть в коде, а не в каком-то конфиге, что служит для связки компонентов. Так что пусть мануалы к этой убогой кривоте курят другие.

Вообще-то @Required вешается на бин. Более того, есть еще @PostConstruct, @PreDestroy.

aka50
()
Ответ на: Spring rules? Ага, конечно от rtvd

1. «Хорошей практикой» считается использовать конструкторы без параметров. Почему хорошей? Объект, созданный через пустой конструктор и далее собираемый через сеттеры изначально не готов к работе. Забыл сеттер - сборка накрылась медным тазом, программа сдохла на пол-пути во время исполнения. Так почему же все-таки рекомендуют именно этот вариант?

Потому, что конструкторы в java без костылей вроде paranamer или debug инфы не сохраняют имена параметров (чтоб санкам икалось), а следовательно конструктор вида

MyClass(int minVal, int maxVal){};

MyClass cc = new MyClass(10, 20);
очень не интуитивен. И указание порядкового номера - тоже радости не вставляет. Было бы в Java что-то вроде да в Runtime:
MyClass cc = new MyClass(minVal=10, maxVal=20);
Тагды setter/getters гимор не нужен был бы.

По поводу последовательности инициализации - выше уже ответили. Не юзай конструкторы.

2. Собираем кучу бинов.. Для этого можно их разложить (компонентность!) по разным файлам и дальше включать один в другой. Не знаю как в 3м, но в 2.х все это сваливалось в одно пространство имен. Из-за чего вылезала куча проблем. Пространства имен, что был придуманны лет 20-30 назад быть может появятся в «самом передовом фреймфорке для Жабы» где-то через.. хе-хе.. 20-30 лет.

Используй разные applicationcontext-ы. И опять же, разве в EJB нет подобных проблем? ;)

5. Про другие прелести, такие как JMS связки, что дико, безбожно конфликтуют с некоторыми либами для Weblogic или мусорный API для работы с базой данных, что еще грязнее чем JDBC я пожалуй продолжать не будут.

Тут согласен. Да. В свое время даже срач был spring vs hibernate.

aka50
()
Ответ на: комментарий от keeper-andrew

re: Быдлокодерство

>>Таки умеет? Удивительно. >ОК, допустим я не знаю спринг :) Не соблаговолит ли уважаемый человек с 3мя годами опыта в нем, глянуть на вот это:

Быдлокодерство. Но для даунов повторюсь:

А уже если ты попутал с циклическими ссылками то ты ССЗБ.

Для тех кто в танке: в моем примере есть просто два бина и циклическая зависимость. Абсолютно законная. То, что спринг туп, и не может понять, в каком порядке инициализировать - проблема спринга. А если Вы этого не понимаете, то Вам можно только посочувствовать.

rtvd ★★★★★
()
Ответ на: комментарий от keeper-andrew

re: сколько бит в байте

> Скажи мне сколько бит и я скажу кто ты :)

Ну в общем-то да. Кое-что сказать можно, услышав от человека ответ на этот вопрос. Впрочем, если он говорит «8» это еще не значит что он дурак.

rtvd ★★★★★
()
Ответ на: комментарий от tailgunner

> По поводу последовательности инициализации - выше уже ответили. Не юзай конструкторы.

Я не собираюсь писать кривоту из кода ради того, чтобы удовлетворить какой-то там спринг. А насчет того что ответили, то повторю еще раз: конфиг мой описывает законную зависимость. То, что поведение спринга зависит от того, в каком порядке дергают бины - его личные проблемы и демонстрация качества этой шняги. А то, что его при этом обожают 95% народу ситуации не изменяет.

rtvd ★★★★★
()
Ответ на: комментарий от aka50

re: @Required

> Вообще-то @Required вешается на бин. Более того, есть еще @PostConstruct, @PreDestroy.

Это нарушает святой принцип: не вноси в код зависимость от IoC контейнера. Когда захочешь соскочить со спринга на что-нибудь более летнее быстро поймешь что значит выражение «огрести проблем по полной».

rtvd ★★★★★
()
Ответ на: re: @Required от rtvd

Когда захочешь соскочить со спринга на что-нибудь более летнее быстро поймешь что значит выражение «огрести проблем по полной».


Уморил. Если в проекте узким местом становится IoC контейнер, то этому проекту уже ничего не поможет.

anonymous
()
Ответ на: комментарий от anonymous

re: @Required

> Уморил. Если в проекте узким местом становится IoC контейнер, то этому проекту уже ничего не поможет.

Ну да. Если в проекте в каждой щели торчат подпорки, специфичные для IoC контейнера, то ему уже ничего не поможет. Т.к. в первую очередь надо выгнать девелоперов и заменить на более толковых.

Короче, простая мысль, которую я пытался донести:

Spring - распиаренный framework, что не может справиться даже с тривиальным. Но вместо того, чтобы пофиксить баг, его создатели решили объявить плохие практики хорошими. Тем не менее, многие принимают аргументы создателей спринга как священные доктрины. А когда им объясняешь, что они неправы - обвиняют в быдлокодерстве.

rtvd ★★★★★
()
Ответ на: re: @Required от rtvd

Spring - распиаренный framework, что не может справиться даже с тривиальным.


За деревьями леса не увидел. Ну нашел документированный нюанс в распиаренном framework'е и что? Нет возможностей обойти эту проблему? Крокодил не ловится, не растет кокос?

Ситуация напоминает басню про слона и моську (в роли слона Spring framework, если что).

anonymous
()
Ответ на: комментарий от aka50

> Используй разные applicationcontext-ы. И опять же, разве в EJB нет подобных проблем? ;)

ОК. У меня есть родительский контекст и несколько дочерних. Бины родительского ссылаются на бины дочерних. Бины из дочерних ссылаются на бины родительского. А теперь вопрос: как все это поднять с этими самыми applicationcontexts?

Я в курсе что можно, но как это сделать без извратов?

А еще вариант: в родительском и дочернем контексте подгружаются properties. Есть желание из дочерного контекста получить проперти родительского.

rtvd ★★★★★
()
Ответ на: комментарий от rtvd

Бины родительского ссылаются на бины дочерних. Бины из дочерних ссылаются на бины родительского.

Есть желание из дочерного контекста получить проперти родительского.


К этому забыли добавить чтобы в Java коде не было зависимостей от IoC контейнера :)

anonymous
()
Ответ на: комментарий от anonymous

Дорогой анонимус, я бы не плевался, если бы это не запарило в свое время. Но я уже давно распрощался с этим фреймворком, о чем ни грамма не жалею.

А что до басни, то есть еще такое выражение «миллионы мух не могут ошибаться»(в роли того, в чем они души нечают - Spring, если что).

rtvd ★★★★★
()
Ответ на: re: Быдлокодерство от rtvd

>Для тех кто в танке: в моем примере есть просто два бина и циклическая зависимость. Абсолютно законная. То, что спринг туп, и не может понять, в каком порядке инициализировать - проблема спринга. А если Вы этого не понимаете, то Вам можно только посочувствовать.

О которой я сразу сказал даже еще не увидев твоего сэмпла. Наличие циклических зависимостей нормально когда есть lazy инициализация а не в application scope. В других случаях это=быдлокодерство.

Знаешь я тоже туп и меня тоже вводит в ступор подобная конструкция. Бины C1 и C2 иметю равные права на то что быть созданными и инициализированными первым. Оспорь. Только учти экстрасенсы в отпуске.

keeper-andrew
()
Ответ на: комментарий от rtvd

>> По поводу последовательности инициализации - выше уже ответили. Не юзай конструкторы.

Я не собираюсь писать кривоту из кода ради того, чтобы удовлетворить какой-то там спринг. А насчет того что ответили, то повторю еще раз: конфиг мой описывает законную зависимость. То, что поведение спринга зависит от того, в каком порядке дергают бины - его личные проблемы и демонстрация качества этой шняги. А то, что его при этом обожают 95% народу ситуации не изменяет.

От спринга твой код кривее не станет. Потому что уже дальше некуда. А доказательств ты уже привел достаточно.

То что ты называешь «законной зависимостью» иди в EJB попробуй прописать. Многие люди назовут твои сэмплы ересью. В спринге такой сатанизм не нужен.

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

Некоторая защита от быдлокодерства там все-таки есть. Вот что это показывает.

А то, что его при этом обожают 95% народу ситуации не изменяет.

Это всего лишь показатель. Но не для еретиков.

keeper-andrew
()
Ответ на: комментарий от keeper-andrew

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

Я уже разжевал достаточно, почему непустые конструкторы это не просто полезная фича языка, я кайне полезная. То, что это не нравится спрингу и Вам - не моя проблема.

И меня не интересует, в каком порядке инициализируются бины C1 и C2 и в этом смысле они имеют равные права на то, чтобы быть созданными первыми. Но только в этом. В спринг нет возможности явно прописать порядок инициализации, поэтому считать порядок записи бинов или порядок lookupов важным - нездорово. Но есть железобетонная причина создать C2 первым: только этот порядок инициализации в принципе возможен. Не согласны? Оспорьте. Только экзорцисты тоже в отпуске.

rtvd ★★★★★
()
Ответ на: re: @Required от rtvd

Вообще-то @Required вешается на бин. Более того, есть еще @PostConstruct, @PreDestroy.

Это нарушает святой принцип: не вноси в код зависимость от IoC контейнера.

Это зависимость от Spring Framework. От IoC никаким образом можно не завистеть (правда придется возможно написать пару спец приблуд, типа BeanPostProcessor-ов)

Когда захочешь соскочить со спринга на что-нибудь более летнее быстро поймешь что значит выражение «огрести проблем по полной».

И спрыгивал. И запрыгивал. Но уж лучше spring , чем самопалы типа MyDao.getDao().doSomethignById(abc)... увольте.

И вообще, интересно, сколько и чего ты успел написать на Spring? Если не понимаешь, что в спринге есть тыща и адын способ сделать то, что тебе нужно. Вот например про @Required могу пару решений подкинуть:

  • 1. Используй кошерные javax.annotation http://java.sun.com/javaee/5/docs/api/javax/annotation/package-frame.html
  • 2. Если ну очень надо что-то свое закидонское - BeanPostProcessor в руки.
  • 3. AOP в конце концов никто не отменял (можено даже в load-time или даже compile-time).

Для справки, попробуй google-injection :) обучить понимать что-то другое... вот уже где 100% вендор лок.

aka50
()
Ответ на: re: @Required от rtvd

Spring - распиаренный framework, что не может справиться даже с тривиальным. Но вместо того, чтобы пофиксить баг, его создатели решили объявить плохие практики хорошими. Тем не менее, многие принимают аргументы создателей спринга как священные доктрины. А когда им объясняешь, что они неправы - обвиняют в быдлокодерстве.

А скажи, мил человек, а чего же посоветуешь, дабы я мог тоже в твою сторону какашками кидаться? А тот как-то толсто. Ага :) . Неужно EJB?

aka50
()
Ответ на: комментарий от rtvd

А еще вариант: в родительском и дочернем контексте подгружаются properties. Есть желание из дочерного контекста получить проперти родительского.

Это ты только что в гугле нашел? :). Как бы на запрос «spring child application context» это первая ссылка.

Но мне реально не приходилось с таким сталкиваться, ибо не люблю properties (в силу сложности управления ими). Properties у меня сугубо локальные без глобализаций. В случае глобальности: jndi или тупо бин.

aka50
()
Ответ на: комментарий от aka50

> А скажи, мил человек, а чего же посоветуешь, дабы я мог тоже в твою сторону какашками кидаться? А тот как-то толсто. Ага :) . Неужно EJB?

А в мою сторону нормально кидаться не выйдет. Недокинуть. ;-) Кстати, на мой вопрос «сколько бит в байте» народ решил перевести стрелки. Что демонстрирует как минимум уровень знаний.

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

Это ты только что в гугле нашел? :). Как бы на запрос «spring child application context» это первая ссылка.

Мимо тазика. Нормальная иерархия контекстов мне была нужна пару лет назад. А Вы лучше почитайте по сами то, что по той ссылке, и попробуйте подумать. Для затравки помедитируйте над этой фразой: «That means that a parent context does not know anything of child contexts.» Вот и вперед делать так, чтобы родительский контекст ссылался на дочерные при таких раскладах.

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

Спасибо огромное, доставило по-взрослому. Я предложил _элементарную_ задачу на dependency injection. Мне ее предлагают решить при помощи уродования кода + аннотаций, пост-процессоров и аспектно-ориентированного программирования. Spring way во всей красе. Сделать простое не можем, посему пиарим свое поделие по жесткой схеме и продаем книжки а-ля «Pro Spring». Неплохой бизнес.

Это типа как если в калькуляторе работает арифметика почти замечательно, но иногда лажа вылезает вроде 4+7=3. Для борьбы с этим есть мануал на 700 страниц с рекомендациями: «Только быдляки прибавляют большее число к меньшему. Надо только меньшее к большему.»

rtvd ★★★★★
()
Ответ на: комментарий от rtvd

>>>> Кстати, на мой вопрос «сколько бит в байте» народ решил перевести стрелки.

а сколько бит в байте?

zapruder
()
Ответ на: комментарий от rtvd

Constructor or setter injection: how do you choose? p. 45 Spring in action, 2nd Ed

_____Constructor injection enforces a strong dependency contract____

elsi vybral constructor injection to ty sam sebe zlobny buratino

ne nravitsja «urodovat kod» - ne ispolzuj Spring

zapruder
()
Ответ на: комментарий от rtvd

А в мою сторону нормально кидаться не выйдет. Недокинуть. ;-)

Хм. Мания величия? А вообще ты опять ушел от ответа :). Дык может все же поделишься великим знанием - чем делать следующие вещи:

  • 1. IoC (чистый незамутненный)
  • 2. Декларативные вещи, типа Transactional или Cacheble.
  • 3. Чтобы зацепить в одноу транзакцию и ibatis (условно) и jdbc (надо бывает).

Как бы есть конечно альтернативы, но pico/nano имеют кучу своих недостатков (ибо пробывал). guice - это ваще пепец (хотя да, шустрый, но код получается связанный что пепец), microkernel - эт ващe EJB. Что у нас там еще... plexus.. там вообще много на static final string ROLE=«blabla»... Tapestry... 4-ка не впечатлила, 5-ку так и не посмотрел...

Ну и остается альтернатива «lookup pattern», но это я тоже проходил, когда использовал NetBeans как RCP. Та еще жопа (оторвать что-то от чего-то - лучше застрелиться, детали уже не помню, ибо ну очень давно было).

Можно еще builder pattern, но это суть статик методы, что тоже беда.

Или еще какая альтернатива есть? (естественно синглетоны со статиками тут же идут в сад).

aka50
()
Ответ на: комментарий от rtvd

Кстати, на мой вопрос «сколько бит в байте» народ решил перевести стрелки.

Ну и да... в байте сколько угодно бит, ибо байт - это единица информации. С другой стороны при наличии гугла, отличить реальные знания, от википедии порой бывает очень сложно ;)

aka50
()

сколько бит в байте?

сколько бит в байте?

zapruder
()
Ответ на: комментарий от zapruder

> _____Constructor injection enforces a strong dependency contract____

Абсолютно точное утверждение. Зависимость получается сильная. Но это не значит, что лажать при выборе пути конструирования бинов позволенно.

ne nravitsja «urodovat kod» - ne ispolzuj Spring

Ну так и не использую. А когда «использовал», то только из-за того, что другие от него писали кипятком. Когда в команде 90% народу юзает спринг а тебе нужно пользоваться библиотеками, что они наколбасили, то выбора почти что нет.

а сколько бит в байте?

Специально для 'zapruder': 'aka50' сказал правильно «сколько угодно». А если точнее, то к-во бит в байте зависит от платформы.

rtvd ★★★★★
()
Ответ на: комментарий от aka50

> Хм. Мания величия? А вообще ты опять ушел от ответа :). Дык может все же поделишься великим знанием - чем делать следующие вещи:

1. IoC (чистый незамутненный)
2. Декларативные вещи, типа Transactional или Cacheble.
3. Чтобы зацепить в одноу транзакцию и ibatis (условно) и jdbc (надо бывает).

Нет никакой мании величия. Просто есть критический взгляд на вещи.

Теперь по пунктам.

1. Я когда-то искал нормальный IoC для жабки. Не обнаружил. Тот же Guice еще мутнее чем Spring. pico / nano / seasar / ... -> туда же.

На данный момент у меня нет жесткой необходимости делать IoC, но когда понадобиться - возможно напишу свой. Если буду писать свой, то конфиг у меня будет чистый и декларативный. Скорей всего a-la python. Контейнер будет инициализировать все так, как нужно, не паря мозг надуманными ограничениями. Аннотации, специфицные для контейнера, будут не нужны. Ну и получить бин можно будет так же как и в спринге: сделал контекст, дернул из него бин.

2. и 3. Пока мне это не было нужно, поэтому я не проводил никаких исследований на эту тему. Посему no comments.

rtvd ★★★★★
()
Ответ на: комментарий от zapruder

Spring Framework eto open source application framework. Hochesh chto to ispravist ili dopolnit' - isprav' i dopolni

Тут выступлю адавокатом.

К сожалению, оно хоть и open source, но очень жесто контролируется, теперь VMWare... по этому что-то «просто исправить» против воли создателей не получится, а тащить свою версию - это еще хуже. А касаемо косяков, то их в спринге много, но обычно они компромисны (т.е. сделано «потому что», а не «вопреки»)

aka50
()
Ответ на: комментарий от aka50

>>>> К сожалению, оно хоть и open source, но очень жесто контролируется, теперь VMWare.

Linux tozhe очень жесто контролируется, i Java tozhe

zapruder
()
Ответ на: комментарий от zapruder

> pilat' a muzhiki-to ne znali! ja figeju s etogo obormota!

Знали. А ты, видимо нет. Иначе бы не писал «6,7,8,9». Видишь разницу между «платформо-зависимо» и «6,7,8,9»? Все еще нет?

Hochesh chto to ispravist ili dopolnit' - isprav' i dopolni

Спасибо за щедрое предложение, но я, пожалуй, воздержусь. Буду себе на зло делать то, что приносит мне деньги. Тем более, что раз любители спринг считают эти баги фичами, то зачем мне срезать кактусу иголки? Пусть продолжают кушать эти иголки и радоваться. :-)

rtvd ★★★★★
()
Ответ на: комментарий от zapruder

Ага. И именно по этому Ёнтерпрайз использует узкий набор дистров с предсказуемой совместимостью ( я имею ввиду стронний софт), а разные «гибкие» и «самопальные» дистры - удел отдельных индивидуумов или маленьких компаний. Дык вот, возвращаясь к спрингу, если не устраивает спринг, проще его сменить на что-то, чем пытаться бежать навстречу паровозу, ибо все равно не заметят. А когда сам станешь паровозом, то уже на лисапеды (пусть и гениальные) будешь с опаской смотреть, т.к. их надо ведь еще и поддерживать.

aka50
()
Ответ на: комментарий от rtvd

получилось что заодно и тебе ответил. Вышел релиз фреймворка Spring 3.0 (комментарий)

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

aka50
()
Ответ на: комментарий от rtvd

Упс, вкладка потерялась, а я оказывается целый трахтат наваял.

На данный момент у меня нет жесткой необходимости делать IoC, но когда понадобиться - возможно напишу свой. Если буду писать свой, то конфиг у меня будет чистый и декларативный. Скорей всего a-la python. Контейнер будет инициализировать все так, как нужно, не паря мозг надуманными ограничениями. Аннотации, специфицные для контейнера, будут не нужны. Ну и получить бин можно будет так же как и в спринге: сделал контекст, дернул из него бин.

Если сможешь написать что-то лучше - это будет замечательно. Хотя я в это не верю :). Т.к. IoC уже существуют тыща и одна штука, а чистая декларативность вернет тебя в spring-1.0 и xml-hell, т.к. описать даже простецкую вещь как @Required потребуется xml файл (ну или какой JSON ты выберешь для этого :) ), а вслучае со спрингом сейчас вообще ничего не надо, достаточно прописать пакет, где лежат твои классы (опционально можно даже @Component или там @Service навесить) и вообще никаких конфигов.

По этому если сравнивать удобство аннотаций и как следствие «привязка» к IoC против чистого IoC, но с кучей внешнего конфигурирования (например в xml), то я пожалуй привяжусь к ioc. К тому же рефакторинг никто не отменял и заменить одни аннотации на другие - без проблем обычно. А вот конфиги заново переписать - это сильно сложнее задача.

Т.е. как сухой остаток: локальность деклараций, даже ценой небольшого вендор лока, существенно лучше, чем держать паралельную структуру конфигов, которые буде едва ли не сложнее перенести на другой IoC, чем заменить аннотации (при условии схожести IoC движков, а не так как guice <> spring)

aka50
()
Ответ на: комментарий от rtvd

>>>> Буду себе на зло делать то, что приносит мне деньги

а сколько детей ты сделал за деньги?

zapruder
()
Ответ на: комментарий от rtvd

>>>> pilat' a muzhiki-to ne znali! ja figeju s etogo obormota!

Знали. А ты, видимо нет. Иначе бы не писал «6,7,8,9».

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

zapruder
()
Ответ на: комментарий от zapruder

>> Буду себе на зло делать то, что приносит мне деньги

а сколько детей ты сделал за деньги?

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

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

Если ты думаешь, что анекдот, сочиненный дядей в твоей деревне, знают во всем мире, то пора тебе топать в школу и изучать географию.

rtvd ★★★★★
()
Ответ на: комментарий от rtvd

>>>> Родитель, что тащится от спринга, вместо того, чтобы делать деньги и обеспечивать семью...

а разрешается так и от спринга тащится и семью обеспечивать? или это запрещено законами шариата?

Если ты думаешь, что анекдот, сочиненный дядей в твоей деревне

госпадя, он действительно не знает этого анекдота.... вот молодежь пошла !!!!!

zapruder
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.