Java, ынтерпрайзненько, реквестирую непотопляемый веб-фреймворк

Spring?

Сомневаюсь, что его забросят.

Spring WebFlow?

Я так и не понял из поста - что нужно то? Фреймворк чисто для рисования веб-мордочек? Или нечто более навороченное, с поддержкой всяких ioc, transactions, jms etc?

Желательно какой-то компромисс.

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

Короче, есть линукс с несколькими предустановленными программами. Нужно написать супер-гипер-вебную админку для линукса. Дойти этот процесс может до чего угодно, вплоть до создания inner systems типа собственной оконной системы на жабаскрипте внутри вебстранички.

Хороший пример, в каком-то смысле, Eclipse и Eclipse Rich Ajax Platform. Но всё же использовать его - самая крайняя мера.

По-моему, ты траванулся грибами.

я не спец по веб, но кажется erlang проекты претендуют на статус непотопляемости

Если процесс может дойти до чего угодно, т.е. заранее известно что он может не уложиться в стандартные компоненты, предоставляемые каким-нибудь веб-фреймворком - бери Spring. Т.е. свзяка получается такая:

- Spring MVC + JSP||Freemaker + JQuery какой-нибудь на клиенте - для реализации самой морды.
- Spring Security - для вопросов безопасности.
- Бины бизнес-логики так-же делаются как spring-объекты.

я юзаю spring mvc

веб-флоу отдельная надтсройка над mvc .. просто mvc будет достаточно.

присоединяюсь

2) Можно взять готовый

Eclipse Equinox p2.

> Нужно написать супер-гипер-вебную админку

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

GlassFish, например, реализует бесшовную интеграцию с OSGi-фреймворками.
http://samolisov.blogspot.com/2010/08/glassfish-osgi-equinox.html

о каких открытых фреймворках ты говоришь? среди них есть веб?

о да, osgi - тру, но что для него хорошего есть уже?

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

Плюсую Spring MVC.

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

Буду оригинален - JSF.

Лично мне нравится.

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

> гвт сейчас очень активно пилится гуглем

в том то и дело, что очень активно, вчера MVP, сегодня все эти Ui биндинги, завтра GWTP и потом никто не знает куда все эти коллбеки совать в какой P или V (грубо говоря)

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

Вообще-то, топикстартеру нужно КОМПЛЕКСНОЕ решение:

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

OSGi является связующим, основой, на которое наворачивается то или иное Web-решение. А для всего нужен сервер приложений, и он есть — Glassfish называется.

Изначальное требование было:

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

Ключевое слово - веб.

И, кстати, нафига нужен osgi в конечном решении - еще очень большой вопрос.

И, кстати, нафига нужен osgi в конечном решении - еще очень большой вопрос.

Для ИНТЕГРАЦИИ всего.

Для ИНТЕГРАЦИИ всего.

Все слова евангелистов от osgi я слышал и не раз. Только вот большой вопрос - стоит ли из админки (а как я понял - что-то вроде нее и нужно топикстартеру) творить огромного монстра с pluggable архитектурой? Имхо - overengineering. Вполне хватит монолита с управляемыми мэйвеном профилями сборки или, что еще проще, несколькими наборами спринговых конфигов под разные конфигурации.

несколькими наборами спринговых конфигов под разные конфигурации.

«Костыли, вы мои, костыли...»

берите за основу Java EE 6 фреймворк (JSF, CDI, JPA, JAX-WS, JAX-RS, JAXB, EJB 3.1, JTA) - там есть все - от работы с БД до веб-морды. Это стандарт поэтому не забросят. Он очень легковесный (в отличии от того же монстрообразного спринга). Для него есть куча документации, стандартов, большое коммунити, 4 сертифицированных реализации. В дополнение можно взять jboss cache для кеширования, richfaces для красивой морды (оба достаточно давние и актуальные продукты, стабильные и вроде бы не прекращают разрабатывать крупнми компаниями).

Да, и не бери спринг. После версии 2.5 он перестал быть лучшим java фреймворком для веба.

Это jee то легковеснее спринга? В каком интересно месте? Единственно где его стоит применять - так это всякие statefull распределенные приложения (что реально необходимо очень редко).

Для него есть куча документации, стандартов, большое коммунити

Только официальная документация по спрингу сильно лучше и собрана в одном месте в отличие от огрызков доки по jee.

richfaces для красивой морды

И лезть в кишки jsf при первой-же необходимости чего-то нестандартного.

Чего такого в 2.5 спринге появилось что он вдруг хуже для веба стал?

>> гвт сейчас очень активно пилится гуглем

в том то и дело, что очень активно

да, есть и такое... немного этот процесс весь смотрится истерично.

>Это jee то легковеснее спринга? В каком интересно месте? Единственно где его стоит применять - так это всякие statefull распределенные приложения (что реально необходимо очень редко).

мне кажется, что ваши знания о jee базируются на 5.0 версии, которая действительно была ужасна и поэтому люди использовали спринг. Я думаю, что java ee 6 вы еще просто не пробовали. Я пробовал и то и то и разрабатывал на спринге несколько лет и на java ee 6 уже год. У меня есть опыт использования и того и того.

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

Spring

мне кажется, что ваши знания о jee базируются на 5.0 версии, которая действительно была ужасна и поэтому люди использовали спринг

На 1.4, 5.0, 6.0

Я пробовал и то и то и разрабатывал на спринге несколько лет и на java ee 6 уже год. У меня есть опыт использования и того и того.

У меня тоже есть. И из моего опыта следует, что спринг как был, так и остается более легковесным и гибким подходом. Поскольку инжектить ejb, даже 3.1 во что-то кроме jsf backing бинов - гемморой. Потому что jsf - негибкая технология с геммороем при написании чего-то выходящего за рамки готовых компонентов. Потому что jax-rx + jsp response не дотягивает до springmvc. И много чего еще.

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

Я сторонник scala+lift. Но советовать эту связку неофитам - слишком на троллинг смахивает :)

Бери старую как говно мамонта (читай стабильную) версию Tomcat, Jetty, Spring MVC и все будет норм. Пиши хорошую модульную програму чтобы потом легко менять имплементацию устаревающих или несовместимых компонетов было легко. Ответственность что мол технология будет жить 10 лет можно только за много денег

>Поскольку инжектить ejb, даже 3.1 во что-то кроме jsf backing бинов - гемморой
в этом плане как раз спринг и CDI одинаковы. Как спринговые бины можно инжектить только в spring-managed бины, так и EJB можно инжектить только в CDI-managed бины.

Угу. Только куча фреймворков изкароппки предоставляет всякие resolvers для спринговых бинов. Tapestry например, gwt насколько я помню, jsf через его view resolver. Ну и вообще - интеграция со спрингом считается хорошим тоном среди фреймворкостроителей (поскольку процентов 70-80 проектов его использует в том или ином виде).

как бы seam 3 предлагает интеграцию через CDI с гораздо большим числом фреймворков - Wicket, JMS и т.д. Вы привели три примера, из которых тапестри давно не используется никем, GWT весьма специфическая штука, а jsf 2.0 искаропки работает с CDI.

Ну и вообще - интеграция со спрингом считается хорошим тоном среди фреймворкостроителей

да, так было. И, может быть, так и будет еще какое-то время.

(поскольку процентов 70-80 проектов его использует в том или ином виде).

ну а тут вы загнули уж слишком. Отнюдь не 70-80.

Вы привели три примера, из которых...

Я просто привел примеры тех технологий, на которых делал реальные системы, а не просто тыкал в свободное время.

да, так было. И, может быть, так и будет еще какое-то время.

Так будет еще очень долго. Spring это не только ioc. У него реально много очень полезных фич. C jdbc - удобнее работать через jdbc template. С jms - через jms template итд. Поэтому вряд-ли он куда-то денется в ближайшее время.

ну а тут вы загнули уж слишком. Отнюдь не 70-80.

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

Вижу три варианта: - struts (один из старейших фреймворков, кто-то до сих пор использует, но он страшноват); - spring; - jsf (входит в стандарт JEE5, JEE6).

С 6 весьма поверхностно знаком. Какой AS посоветуешь? JBoss 7 или Glassfish 3.1.1?

мы работаем под gf 3.0.1, так как 3.1 дико глючный, а до 3.1.1 руки не дошли пока попробовать.

UI - GWT (кроссбраузерность, Rest, Java,...)

ServerSide - любой servlet-контейнер (в конце концов, всегда можно сделать upgrade, например из Tomcat в GlassFish) + Restlet-движок (подходящая имплементация JAX-RS)

зачем, вообще, Вам FrameWork ?

1. Spring Web MVC + JSP + Tiles
2. JSF
как по мне, так хорошие

на каком фреймворке остановились?

Пока остановился только на том, что процессинг данных/сообщений в бекенде сделаю вообще на эрланге.

Json api со стороны java - на Jackson, WSDL - на Axis2.

HTML пока рендерю чем придется (ручками :)