jikezНа сколько я знаю в JDeveloper есть поддержка и Struts и JSF
Я бы всётаки стал изучать JSF, всё как никак SUN'ом декларируется как стандарт.
Как уже припарил этот дурацкий аргумент - "стандарт". J2EE стандарты тихонько плачут в углу, когда появляется более или менее адекватная opensource альтернатива.

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

Ну и не все sun стандарты удачные, например sql часть в jstl. Мне кажется что за такое sun-овцем самим стыдно.
По пункту №1 есть замечаточный пример. Это сервлеты. Все ими пользуются. Но хоть кто нибудть может сказать что он использует не HTTP реализацию сервлетов? Ага. Вот и думаешь после этого, а на кой было от HTTP абстрагироватся?

3. Есть ещё один важный пункт. http://rsdn.ru/Forum/Message.aspx?mid=2438762&only=1 . Которому дали хороший термин "Corner cases". Это разные неприятные мелочи. Которые либо не упомянуты, либо не продуманы спецификацией. Убогий Servlet URL маппинг. Не специфицированя кластеризация. Не специфицированый процесс деплоймента. Не понятная реализация песимистического лока в EJB3... и много другого, что не делает жизнь лучше.

jikezНе важно где кому стыдно, но при использовании стандартов уж до боли приятно когда у тебя один и тот же проект деплоится под разными Application Server'ами без дополнительных танцев с бубнами.
и не надо чесать репу когда у тебя в логах туева хуча эксепшенов по непонятным причинам :(

Это все миф и неверные догадки. Аргументирую:
1) Деплоймент дескрипторы зачастую надо переписывать.
2) Разные датасорсы, логирование и многое другое надо конфигурять на конкретном сервере.
3) Переезд любого серьезного приложения на другой сервер, требует как минимум детального тестирования на новом сервере. И чем больше привязка приложения к J2EE тем больше аспектов надо тестировать. А вот если к примеру проект использует не JSF а Spring MVC + Velocity. То все что касается web слоя будет одинаково работать на всех серверах. Потому что привязки к конкретному серверу там нет.

Так что принцип "написано однажды - работает везде" для "нестандартных" решений работает гораздо лучше чем для "стандартных" J2EE решений. Потому что нестандартные действительно не зависят от сервера приолжений.

wessenГениально, особенно если учесть то, что сервер приложений это реализация JEE.
Что тут гениального? J2EE не покрывает целый ряд аспектов, в результате чего каждый сервер реализует эти аспекты как угодно.

wessenХочешь сказать, что приложение использовавшее хибер будет легче переносить, чем приложение использовавшее EJB?

Да.

wessen
Может конечно оно и так, вот только нахрена тогда сервер приложений вообще нужен, если свести к минимуму использование J2EE?

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

wessen
Я не случайно привер пример с хибером, т.к. дело с ним не имел, а вот с остальным, ejb, веб сервисы, JSF и т.д. никаких проблем при переносе не возникало, естетсвенно спецефичные для СП дескрипторы приходилось писать.
А вот замечательнейший пример между прочим. Давай разовьем тему. Итак есть EJB3 persistence. И есть всего 2 его реализации это Hibernate и TopLink. И на сколько бы тебе хибер не казался не стандартным, с этим ничего не попишешь он один из немногих кто реализует спеку EJB3 persistence(не помню какое там у неё точное название).

Так вот. Взять к примеру какой-нить метод. EntityManager.lock. Я вот знаю, в случае хибера он ложиться на хибернейтовский метод lock который делает SELECT FOR UPDATE.
Но теперь я хочу портировать своё приложение с JBoss на Oracle AS. И скажи мне с пол пинка. Что буде происходить на TopLink с вызовом "стандартного" метода EntityManager.lock? А если чур в TopLink не заглядывать а попытатся разобратся по спецификации и EntityManager API doc?
Вот это-то и называется, здравтсуй жпа - новый год. Ты не знаешь что там реально происходит. И не сможешь угадать. И не сможешь предсказать заработает ли этот метод при переезде на другой сервер как тебе надо или нет.

wessenА вот нестандартный хибер, судя по документации Jboss встроен туда намертво и думаю что геморой при переносе приложения его использующего, возникнет.
Это тебя в какое-то словоблудие понесло. Хибернейт реализует "стнадартную" спеку EJB3. Это для тебя новость или сюрприз?

vas0Стандарты вообще дело хорошее, никто не говорит что это зло.

Я говорю. И не только я.

termit31Очень хорошая дискуссия, но участники увлеклись деталями. Хотелось бы услышать от каждого обобщение сказанного. Т.е. "я считаю, что Struts> JSF> Spring", "а я что Struts< JSF< Spring". Хочется услышать совет. Заранее спасибо.
Чтобы нормально определиться надо смотреть что у вас уже понаписано на JSP. Но если только субъективно, то.
Spring MVC рулит потому что простой и потому что интегрится 8)) в Spring.
JSF рулит потому что компонентный, но не рулит, потому что "стандарт", который трактуют кто как хочет. И потому что далек от HTML. Хотя facelets как-то дело и поправляют, но все же непонятно для чего тогда был JSF в изначальной интерпритации которая выглядела как сплошной JSTL.
Struts 1 вообще не рулит. Struts 2 немного подруливает, но только в сравнении со Struts 1. Никаких особых его достоинств перед первыми двумя вариантами я не знаю.

vas03. Beehive
Расскажи.

vas0Вообще самому интересно как люди оценивають такие вещи как: Web Work, Struts 2, JSF, SEAM и какой бы рейтинг составили другие.
Struts 2 это и есть Web Work. JSF в принципе рулит готовым набором компонент и скоростью разработки простых решений. Когда начинаются нюансы то с ним приходится повозится. Ещё его "стандартность" отпугивает тем что на разных серверах он может работать поразному. Поэтому наверное проще одну реализацию просто в виде либы таскать.
SEAM, ну на всяких простых примерах он конечно же хорош. Но во-первых это железная привязка к EJB3 и JSF, во-вторых я уверен что с его абстрагированостью в мелочах и начнутся затыки.

vas0Вообще при выборе framework, на мой взгляд очень многое зависит от IDE которую будешь использовать, насколько он хорошо со средой интегрирован, есть ли хорошие плагины и т.п.
Плох тот фреймверк для которого необходима интеграция с IDE. Хороший фреймверк интегрировать не надо, потому что он должен быть максимально близок к Java и HTML. С ними любая IDE справится. Ну и немного XML для связки.

wessenЯ имел ввиду те далекие времена, когда ejb были версии 2.х и с хибером их объединяло только то, что это были ORM средства. Не думаю, что тогда еще, нестандартный хибер, было так просто таскать по разным серверам приложений.
Ты меня все больше удивляешь своими умозаключениями. Хибер от того и стал популярным что заруливал EJB2 по всем параметрам. А в чем сложность таскать его по разным серверам ты можешь объяснить? Это всего лишь либа. Положил её и она работает. На ЛЮБОМ сервере. А не как овняный CMP. На одном сервере 100 запросов а на другом 200 для одной и той же операции.

wessenА что качается ejb 3.0 и приведенного метода EntityManager.lock, так ведь так ко всему можно придраться и к сервлетам и к jsp и к JMS... К JSP нельзя он привмитивный поэтому почти везде почти одинакво компилируется без всяких загадок.

wessenЭто уже дело программстов реализующих стандарты. И если мой сервлет работает не так, как написано в спецификации, то ну ее в жпу такую реализацию и СП вместе сней.
Блин. А если в спецификации не написано то что??? По-моему ну её в пу такую спецификацию, к которой всегда что-то да не написано.

wessen И если мой сервлет работает не так, как написано в спецификации, то ну ее в жпу такую реализацию и СП вместе сней.
Кстати о сервлетах. У меня тут тоже есть хороший пример недоработок в спецификации. Претензия конкретно к servlet url mapping. В далекие времена, кажется в WebSphere, url mapping был довольно крутой. С включениями исключениями и чуть ли даже не регэкспами. Уже точно не помню. Потом появилась спецификация Servlet 2.4 (или может даже более ранняя версия) и WebSpherу переделали на неё. И там теперь точно такой же убогий маппинг как и везде. Возможности исключения делать из маппинга - нет. Поэтому сейчас все извращаются с суффиксами (.form в примерах Sprnig MVC или .do в Struts)
А ведь сделать хотя бы что-то близкое к регулярным выражениям уже просят давно. А воз и ныне там. Все этим новым EJB/JSF заняты.

vas0Здесь я не согласен, не хотел бы я оказаться во временах когда не было J2EE. И каждый начинал придумывать свою безопастность, свою EJB, ... свой applicatin server. Ну или пойти еще дальше и отбрать стандарт SQL 92, что тогда делать то?
"Свою" безопасность уже придумали и все используют Acegis называется.
Свой EJB это Spring IoC + Spring вездесущая интеграция.
А сервер он и так у всех свой. 8)

am_sasaстандарт, поддерживаемый всеми вендорами или практически всеми, не зависит от J2EE, а решает те же задачи, бин -> html
Гы, ещё один со "стандартом". Вот только большинство фреймверков решают задачу Java - HTML, в то время как XSLT решает задачу Java -> XML -> HTML. И на кой тут лишняя и тормозная прослойка ещё тот вопрос.

wessenУ тебя такая неприязнь ко всем спецификациям или только касательно entity ejb?
Ко всем. Только "неприязнь" это субъективное. А у меня негативное отношение основаное на ряде фактов. ВСЕ спецификации жутко тормозят развитие платформы в целом. Субъективно около 80% спецификаций J2EE имеет слабые места и недоработки. Будем конкретно каждую перебирать?

funikovyuri Blazkowicz Будем конкретно каждую перебирать?
А почему нет - вот к примеру jdbc. Еслиб не sun сейчас бы сидели на деревьях, притом каждый на своем...
Ну и спеки на JVM и язык тоже только тормозят. Даешь как в C++ - чтоб каждый производительно jvm чего нибудь свое прикрутил...

Вам, судя по всему, на microsoft.com надо - так так и делают...

Идите лесом со своим чтением между строк. Речь конкретно о J2EE. Спецификации JDBC/JVM туда не входят. Хотя в разных списках о J2EE JDBC зачастую включают по неведомым причинам.


funikovyuriну еще jms - это конечно тоже великий тормоз! Этож так не удобно для программиста - один раз выучить и понять. Лучше чтоб у каждого вендора чего-нибудь свое было!

Как уже сказал выше JMS одно из немногих что продумано достаточно хорошо. По двум причинам. Это спецификация относительно простая и она не пытается покрыть все и вся.

funikovyuriJTA - тоже фигня, про jmx куча подобных мелочей я вообще молчу.
JTA к сожалению знаю поверхностно. И от его использования в принципе не отказываюсь. JMX братно не J2EE. Отдельная спецификация в себе.

funikovyuriНу так выражайтесь яснее... а то несколькими постами выше заявляли что так относитесь ко всем стандартам.
Ну, так читайте весь трид а не отдельные предложения. Все стандарты замедляют развитие это раз. Стандарты до реализаций это зачастую зло - два. Конкретно J2EE спецификация имеет в себе целый ряд недоработок это три.

funikovyuriОтлично, одна есть. Как любитель hibernate я думаю EJB3.0 тоже должны были приветствовать. И метод #lock() при всем уважении погоды тут не делает.
Просто у меня уже нет никакого желанию копать EJB3 персистенс глубже после того что я вижу там нет нормально реализации пессимистичного лока. Я уверен кто уже начал писать крупный проект, может поделится остальными граблями.
Использовать же весь EJB3 тоже нет желания во-первых из-за ограниченной облати классов где работает инжекция, во-вторых из-за вездесущих аннотаций которые перегружают код. А так же показывают чудеса отсутствия гибкости в ряде ситуаций.

funikovyuriЕсть еще JavaMail, JCA и т.д. http://java.sun.com/javaee/technologies/
JavaMail достаточно убогое API, но все по привычке пользуются потому что альтернатив-то и нет. То же самое как с сервлетами. Разобратся их ещё можно до ума доводить ого-го.
JCA кто-то реально в проектах пользует?

funikovyuriДействительно неудачной вещью были только EJB < 3 - но это проблема не стандартов как таковых, а вообще архитектуры которую тогда считали правильной.
Как по мне EJB3 с JSF точно такая же неудача.

funikovyuriНельзя делать выводы о вреде стандартов только на основе примеров типа spring и hibernate.
Ой, можно подумать все мои утверждения выше только об этих двоих. Не надо мне приписывать то чего нет. Выше я уже привел так же ряд аргументов не имеющих отношения к этим двум решениям

funikovyuriКроме них, единственный путь который я знаю - это путь MS - он imho базируется на 2х вещах - 1. никогда не идти по непроверенному пути(т.е. никогда ничего не изобретать) 2) периодически начинать с нуля. Мне такое решение не нравиться намного больше чем некоторый overhead с открытыми спецификациями.
Opensource уже давно двигает Java гораздо больше J2EE. Если бы не opensource .NET бы уже отхватил гораздо большую порцию рынка.