Есть проект, который использует jsf в качестве web framework'a. Есть идея заменить его на что то полегче, у кого-нибудь была подобная практика ? как думаете на сколько легко это будет сделать, учитывая что проект уже запушен и работает. 

P.S. заменить хочется потому что фирма в своих проектах jsf не использует + предстоит делать достаточно большую доработку + есть подозрения в тормазнутости jsf, а одно из пожеланий клиента, было как раз сделать приложение побыстрее.

Был такой эпизод когда для быстродействия пришлось заменять все JSP на сгенерированные Jasper'ом сервлеты с последующей рукопашной оптимизацией сервлетов с убиванием всяких ютилити/хелпер классов и проч. лабуды.

Не знаю как в вашем случае подойдет такая техника или нет. Потом конечно поддержка такого кода - врагу не пожелаешь. Все зависит от размера оверхеда создаваемого фреймворком: всякие кастом теги и проч.

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

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

Это сообщение отредактировал(а) COVD - 7.11.2009, 14:44

Смена технологии это всегда дополнительные риски.
Для начала можно попытаться оптимизировать приложение, а не "жечь мосты". Как минимум нужно выяснить узкие места и определить, что  другой фреймворк действительно поможет. А то начнете использовать wicket, и окажется что проблема была в DAO - будет много потерянного времени и денег.

Мы в своем проекте поменяли Facelets+JSF(Tomahawk) на Tiles+Freemarker

Было это на достаточно раннем этапе разработки сайта (примерно 25% общей функциональности на тот момент).
Но все равно это вызвало неслабую дискуссию.
Если бы нужно было сейчас переходить - я бы не за что не взялся - слишком много перелопачивать.

В принципе по нашим замерам некоторый прирост скорости загрузки страниц после смены технологий появился (~15%).
ИМХО, в случае большого, готового и главное работающего проекта оно того не стоит.

Может есть возможность ускорения за счет иных ресурсов.

Посчитайте стоимость рабочего времени программистов требуемого на изменения и прикиньте сколько "железа" можно на эти деньги купить. )))

Обязательно посмотрите Apache Tapestry 5 - шустрее jsp будет, но в целом нужно вначале выяснить где тормоза, а потом рубить...

Это сообщение отредактировал(а) Foror - 10.11.2009, 22:32

Граждане программисты! Вы окружены ... всякой дрянью!

Tapestry, JSF, JSP - это всё вчерашний день! 

Struts, Wicket и много других - туда же.

Если хотите ничего почти нового не учить а знаете только жаву и HTML - то это для вас.

Осталось прочитать где-то 10 страниц и полный вперёд. Будет лаконично, красиво и работать очень бывстро. Называется это HybridJava. Новейшая отечественная разработка - только пару месяцев как всерьёз заработала.

Не пожалеете.

Предупреждение - вещь нетривиальная, тем не менее. 
Проверено - индуистам не по мозгам.

Это сообщение отредактировал(а) AlexSerov - 22.11.2009, 02:52

цитата по линку (http://www.hybridserverpages.com/language.html):

Variables

HybridJava variables are basically Java variables. They may be declared and used within the Hybrid areas of the code using standard Java syntax. Definition of a widget attribute also creates a variable visible inside the widget body. Default type of an attribute is String:



ты прикалываешься?  написан какой-то "кучкой" энтузиастов. иди читай SpringMVC + Velocity/FreeMarker.
не дай бог новичёк какой прочитает твои слова и утопает вслед за смертью.

Признаю, в документации была путаница, исправлено. 
HybridJava version 0.97 released. 


Это сообщение отредактировал(а) AlexSerov - 30.11.2009, 23:56