GregTkно Spring прозрачнее.

Ну тут конечно можно поспорить:)

авторКонечно Spring. Я потратил просто охрененное количество времени на говнкод от JBoss.

Много говнокода и там и там, а еще больше в коде обычного программиста, такого как Вы или я.
Вообще я бы советовал изучить и то и то, но начинать со спринга и изучить его подробнее чем Seam, просто по той причине, что я дофига раз сталкивался с приложениями, использующими Seam и одновременно Spring, для определенного круга задач, а вот наоборот - ни разу не видел.

Также зависит от того в какой организации работаете и над какими проектами - если корпорат, то велик риск столкнуться с EJB, а тут уже и до Seam рукой подать. В таком случае уделите больше внимания симу, а спринг - только основы. Но начинать все же советую все-таки со спринга.

schwaНа seam уже поздно делать ставки т.к.
http://www.infoq.com/news/2012/04/seam-deltaspike At the beginning of this year JBoss released version 3.1 of the Seam Web framework. However this is not just another minor numbered update in the Seam timeline. Instead, this version is the last "bundled" release of Seam, marking an important milestone. Future development will happen in a different manner since the effort is now focused on Apache DeltaSpike.

Я думаю имелся ввиду стек технологий а не отдельный Seam3.

GregTkзабыл ник,
хвалёная интеграция с EJB в реальных задач мне нафиг не нужна, так как уровень EJB и Web приложения у меня не пересекался.
Ключевое выделено
GregTkЕсли говорить отдельно про EJB и Spring, то тут наверное сложно однозначно говорить за и против. Другое дело что зная Spring или EJB, то на основе одного их них второй осваивается быстро.

Тут полностью согласен.
GregTkПро говнокод: незнаю как в версиях JBoss 6 - 7, но в предыдущих это просто ад, постоянно паришься с какими-то мелкими багами.(часто маялся с JAAS и JMS реализацией)

Возможно, но можно ведь и на другом сервере деплоить и разрабатывать?
GregTkСам Seam меня вообще ставит в тупик, вот скажите нахрена он по 5 вызовов делает одного и того же геттера?

Эт где так? Если это то о чем я думаю - то это вина JSF а вовсе не сима)
GregTkВообщем любой кто хочет работать более или менее с простыми и прозрачными вещами я советую Spring 3.1 + любой понравившийся Web-GUI.

Резонно, ничего не имею против такого варианта.

авторС большим удовольствие услышу лестные отзывы человека, который писал на Spring, а потом переехал Seam+EJB и до сих пор счастлив.
Лично меня они оба парят, поэтому слез что с одного, что с другого. В случае если пишешь админку для корпоратива - и выбрал JSF, Seam однозначно лучше чем спринг, во всех остальных случаях спринг наверное предпочтительнее.

GregTkзабыл ник,
Улыбнуло,

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

GregTkя как это не странно говорю о реальных проектах

Ну а я конечно рассуждаю о сферическом коне в ваккууме:)
GregTkа если вы слой отображения легко смешиваете со слоем бизнес логики то в моём мире это не приемлемо

Интересный вывод, логику можете обьяснить? Или даже дальше пойдем - Спринг как-то этому препятствует? И если да, то что в нем есть чего нету в Seam(CDI, Weld - нужное подчеркнуть)? И да, напомню что я советовал начать изучение все-таки со спринга(на всякий случай напоминаю).

GregTkИ кстати если такая клёвая интеграция то на кой чёрт в Seam свой Security Layer чем их JAAS не устроил? И кстати как там у них вообще интеграция с JAAS, раньше она очень глючила.

Я работал с симом года 2 назад - насколько я помню их секьюрити - всего лишь предполагалась как удобная обертка для JAAS, который на мой взгляд ппц как переусложнен. Глючила, возможно - помню пару моментов, что там сейчас - хз. С другой стороны - а что не глючит?:) Я вам могу сказать что сделать инеграцию Spring Security + SAML - проще убиться, попробуйте подебажить Spring Security в свободное от работы время, то еще удовольствие.

GregTkОх уж мне эта вакуумная админка для корпоратива, я вот на GWT тоже самое писал с EJB3, и на Spring + Vaadin. И после JSF+Seam это как свежий воздух, чем так круто-то? Взять то можно что угодно, вопрос нафига ?

Вот это то, о чем я говорил - во-первых я сказал, что если уже был выбран JSF как технология, а это происходит не так редко как вы думаете. Реалии таковы, не буду вдаваться в рассуждения почему это так, что технологии в крупных компаниях спускают сверху, зачем-то покупают WebLogic , оказывается что у них стандарт - делать UI для интранета на JSF и т.д и т.п. Так вот моя реплика была о том, что если это все спущено сверху - то логичнее юзать Seam+JSF, естественно можно писать на чем угодно, а еще лучше писать на том, что знаешь. Мне как разработчику RichFaces, естественно проще было писать на JSF, хотя я его мягко говоря недолюбливаю.

GregTkМне реально интересно узнать что я пропустил при работе с Seam, может и правда крут :) А я тут какой-то не тот Seam юзал и вообще он няшный :)

Примите три утверждения, и если постараетесь, вы наконец поймете мою точку зрения
1) Баги есть всегда и везде - в любом продукте, просто где-то больше - где-то меньше
2) После того как вы овладели какой-то платформой или фреймворком и знаете подводные камни и способны их обойти - вам станет казаться, что быстрее лучше и проще разрабатывать на ней, чем изучать и внедрять другую,пусть даже многообещающую
3) Технологии не всегда можно выбирать самому.


GregTkНе нужно давить авторитетом только, пример какой-нибудь приведите, где seam рвёт spring как тузик грелку.

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

GregTkА то я когда начинал с Seam разбиратся один умник прыгал и читал мантры "стандарт, EJB, круто" и я на это купился, не хочу чтоб ТС на такое купился тоже.

Ну клоуны(не вы, а тот кто мямлил про стандарты) всегда были есть и будут есть:) Технология выбирается(если выбирается) под задачу, а не потому что это стандарт. А то, что вы купились - вам урок, но не стоит переносить единственный негативный опыт на систему разработки в целом.
В данный момент мы используем EJB практически исключительно из-за JMS, спринг для секьюрити - хотя как я уже говорил SAML интеграция там косячная, но все не найдется времени чтобы переписать, и о чудо! - все остальное вообще не юзает ни спринг ни ejb и чувствует себя вполне так неплохо.