забыл никBlazkowiczК слову, на JavaScript + Servlet (или любой другой простейший фреймверк) задача решается на много проще в стиле COMET.
Каким-нить jQuery плагином биндится на AJAX запрос к серверу. А сервер без всяких рукописных потоков запускает долгоиграющую задачу и пишет лог в response. JavaScript вычитывает лог частями и обновляет какой-нибудь DIV содержимым.
Реализация простейшая. Никаких своих запускалок потоков и асинхронных задач. JSF - зло.
в точку) трудно не согласиться
Всему свое место.
На каком-нибудь хомячке и прокатит, особенно если безопасность не интересует.
JSF это не только рендерер html, не забываем, что это еще и реализация jsr спецификаций

забыл никivanraпропущено...

Всему свое место.
На каком-нибудь хомячке и прокатит, особенно если безопасность не интересует.
JSF это не только рендерер html, не забываем, что это еще и реализация jsr спецификаций

при чем тут спецификации? если уж говорить о них, то вспомните к примеру EJB2, наверное все кто не следовал ей глупцы? Хотя вопрос конечно не об этом. JSF is overabstracted bull-shit. Я не вижу ни одной задачи, в которой бы он давал хоть какие-то весомые преимущества по сравнению с другими фреймворками, и как показывает этот пример, в некоторых задачах простые сервлеты рвут говноjsf в пух и прах.
Странный спор. Я пишу "всему свое место", вы - "сервлеты в некоторых задачах". О чем спорим? :)
Ну подумайте, доверитесь ли вы "простому" сервлету решение какой-нибудь административной или финансовой задачи? Например, просто так, вне контекста приложения, поменять пароль пользователя или выполнить транзакцию по счету? Не FacesContext, так какой - нибудь другой контекст придется иметь под рукой.
Я уже не говорю о портлетах, где клиент даже не знает, на каком сервере запущено приложение.