Pull to refresh

Comments 133

Уважаемый Сергей, ваш технологический стриптиз был очень познавателен. Спасибо.

Вопрос — а что Вы рассматривали в качестве альтернативы Tapestry, если рассматривали?
Рассматривал JBoss Seam (по результатам какого-то обзорного тестирования он оказался очень «тяжелым»), и wicket — год назад начитался про него на англоязычных форумах гадостей, что дескать очень сырой. Сейчас, возможно, с ним стоит поэкспериментировать.
Ясно. Всегда был уверен, что Tapestry — для портальных тяжелых решений, но после вашего отчета попробую на него посмотреть еще раз.

Hibernate Shards сейчас еще сырой, было бы интересно прочесть ваше мнение по поводу его применимости.

Буду ждать новостей от вас по этой теме на Хабре.
Tapestry, на самом деле, гораздо легче классических портальных решений на базе JSR-168. Здесь на Хабре и статья отличная на тему Tapestry была.

Да, с шардингом будем ближе к делу обмозговывать что к чему, возможно как-нибудь PL\Proxy красиво обойдемся.

Спасибо за +1 :)
Не за что. Думаю, там не только я один постарался :)
Цель разработчкика Tapestry 5 — очень сильно оптимизировать его по скорости. Хотя он уже достаточно быстр. Т.е. предназначение — массовые веб проекты.

К примеру, там вместо рекурсивного обхода дерева компонент реализован обход оптимизированного автомата состояний, что дает дает существенный выигрыш. Смотрите его блог — Speeding up Tapestry 5.1
Что мне не понравилось в современном Wicket'е:

  • не оптимизирован для экономии памяти — это принципиальная позиция разработчиков. Например баг в экономном StatelessForm не фиксился на протяжении многих месяцев, потому что это «не приоритетно» — см. StatelessForm — problem with parameters after validation fails
  • не интуитивен для веб разработчиков


С другой стороны, для относительно небольшой аудитории (приблизительное использование HttpSession на пользователя 10-200 килобайт) и сайта со сложной динамической структурой, Wicket очень хорош.
Сложной динамической структурой страниц.
А использовать Jetty вместо томката не пробовали?
У нас Jetty используется на локальных машинах разработчиков (Run-Jetty-Run) для разработки. На production Jetty ставить не пробовали, но, если что, то уверен, что проблем с ним не будет.
jetty вполне хорошо держит нагрузки — его используют Google AppEngine и LinkedIn. Отличная статья, кстати…
Спасибо огромное за информацию, если с Tomcat вдруг будут проблемы — будем знать на что соскочить :)
По большому счету, мы еще оптимизацией не занимались, но когда руки дойдут, будем рассматривать переход на Jetty как один из путей оптимизации.
Просто мне кажется, что это могло бы положительно сказаться на производительности.
А есть какие-нибудь свежие и объективные сравнительные тесты производительности сервлетного контейнера в Tomcat и Jetty?
Есть только тесты по 6 томкату и 6 джетти — там раздача статического контента, джетти в 1,5 — 2 раза хуже. А вот по динамике тестов я не находил.
А можно ссылки или описание эксперимента? Я встречал сравнения, где они наравне, кроме некоторых случаев, когда Jetty быстрее.
Надо гуглить по «Jetty vs Tomcat benchmark».
Очень познавательно, даже если с джавой знаком вскользь. Спасибо за статью.
Скажите, а на какие конкретно нагрузки вы сейчас рассчитываете?
Поскольку естественная нагрузка сейчас небольшая, мы проверяли наш сайт на синтетических нагрузочных тестах, эмулирующих работу пользователей по различным сценариям. Получилось, что мы стабильно выдерживаем в среднем 320 разнородных запросов в секунду. Это при том условии, что тонким тюнингом кода приложения, БД и ОС мы еще не занимались, и кэширования пока вообще никакого не прикрутили.
320 запросов в секунду, это та нагрузка которую держит приложение на описанном Вами парке?
Да, но тут нужно понимать, что при этом «узким местом» являются сервера приложений, загруженные примерно на 80%, сервера балансировки нагрузки и СУБД практически отдыхали, их загрузка была 5-10%
При дальнейшем увеличении нагрузки на серверах приложений сильно возрастали накладные расходы на сборку мусора, и потихоньку начинали копиться очереди запросов. Так что еще есть что тюнинговать, но пока это для нас не первоприоритетная задача, так как таких нагрузок у нас еще нет, а реальный профиль нагрузки скорее всего будет существенно отличаться от нашего синтетического. Ждем реальную статистику.
Ну то что для балансеров и для базы(если запросы нормальные) это вообще не нагрузка оно и так понятно, но вот, что при таком количестве запросов кластер tomcat'ов выдавал такие показатели более чем странно. Опять же синтетический тест скорей всего будет показывать результаты получше, чем боевая нагрузка (из практики).
По поводу sticky session, у вас используется, потому что вы храните информацию залогиненого пользователя в сессии томката? Если так то я бы отказался от этого, потому что как показывает практика хранение объектов в сессии ведет к неспособности приложения жить под нагрузкой.
А на какие в среднем нагрузки стоит ориентироваться на один аппаратный сервер, чтобы это считалось «нормальным»? Профилировщиками пока приложение не ковыряли, возможно какие-то блокировки в коде все же присутствуют, будем над этим работать. Благо запас еще огромный.
По синтетическому тесту — не соглашусь, у нас он более жестокий, нежели пользователи. Практически все сценарии — на обновление данных, хотя в реальности люди гораздо больше читают и качают, чем пишут и загружают.
У нас в сессии лежит минимум данных, в основном аутентификационная информация. В подавляющем большинстве случаев у нас используется активационный контекст Tapestry, позволяющий хранить состояние в URL.
А сколько front-end серверов было, когда вы получили 320 запросов?
Сколько по вашем оценкам это одновременных пользователей?
Два.
Сложно жесткий синтетический тест перевести в реальных пользователей, так вот навскидку даже и не скажу. Со временем соберем статистику запросов, усредним и тогда подсчитаем :)
Кстати, большое спасибо за оценку!
Интересно было бы узнать про технико-экономическое обоснование такой архитектуры
Есть обоснование, но оно больше технико-, нежели экономическое: была поставлена задача разработать движок для социальной сети таким образом, чтобы система была отказоустойчивая, горизонтально масштабируемая, и обслуживание системы могло бы производиться без остановки сервиса. Кроме того, изначально хотели запустить массированную маркетинговую компанию, так что сразу после запуска ожидался вал народу. Соответственно, сразу готовились к хорошим нагрузкам. Изначально можно было бы, конечно, двумя серверами обойтись, а потом размасштабироваться, но руководство поддержало решение «сразу делать хорошо и надолго». Так и сделали.
Спасибо за статью. Побольше бы таких.

Руководство это заказчики? Просто обычно «сразу делать хорошо и надолго» от инвесторов редко услышишь.
Всегда пожалуйста!
Да, нам действительно повезло с инвесторами :)
ох, я, как большой нелюбитель явы — по новому на нее посмотрел и, кажись, начинаю менять свое мнение, спасибо Вам!
по крайней мере — попробуйте. Java сейчас и, скажем, пять лет назад — две совсем большие разницы. Всегда пожалуйста!
поддерживаю предпредыдущего оратора: во сколько встал проект? хотя бы порядок
ну или хотя бы планируемый срок окупаемости?
Порядок — шесть нулей (руб). Подробности, к сожалению, разглашать не имею права.
а планируемый срок окупаемости?
можете разгласить, когда вы планируете получить прибыль?
К сожалению, ни по срокам, ни по способам монетизации комментариев давать не имею полномочий. Единственное что могу сказать — они есть, они вполне конкретные и активная работа с партнерами в этом направлении уже начата.
Сразу вопрос — чем вы круче Скриблера, с которым уже ознакомилась аудитория Хабра?
Я, к сожалению, мало знаю про Скриблер, поэтому сравнивать вот так сходу не могу, но, насколько я знаю, мы «играем на разных полях». По функционалу везде примерно одно и то же.
не могу согласиться, просмотрите подробнее.
С чем не согласны?
На что обратить внимание при осмотре?
Для начала скажу о том, что я один из программистов Скрибблера, ну и, соотвественно,  просматриваю, как развиваются события у других проектов с нашей же тематикой.

Начнем с простого:
1. Расписания на кампусе выглядят в виде добавления событий, что неправильно.
Scribbler: редактирование расписаний вынесено в отдельную сущность сайта.

2. Загружать можно файлы объемом не более 30Мб, а что делать если вдруг нужно выложить видео-лекцию?
Scribbler: рабочий стол.

3. Wiki-учебник ведет на какой то сайт letopisi.ru, вот этого я не понимаю, зачем, лучше было бы убрать этот пункт, до тех пор пока не запрогали что то внутри проекта.
Scribbler: коллективная работа с документами есть, что будет потом не могу сказать, но будет круто.

4. На сайте есть что нибудь повесомей кампусов (сообществ)?
Scribbler: Основная еденица — группа, сообщеста — круг людей по интересам.

5. Как мне отследить активность друзей?
Scribbler: Лента активности

6. Какова миссия проекта campus.ru, создавать кампусы?Scribbler: помочь студенту в учебе, в плане учебы

7. Работа — это джоб сервис или ссылки на сайты с работой?
Scribbler: будет джоб сервис.

В общем архитектура сайта, наверно,  и отличная, но я не понимаю, какова цель проекта.

Был такой проект studbox.ru, но он почему-то теперь закрыт, решал больше задач, чем в данный момент campus.ru, надеюсь, со временем функционал пополнится.

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

по поводу Dojo, благодаря тому, что в нем дофигища всего готово, он тяжелый, потому стоило бы взглянуть в сторону mootools или jquery, и самим дописать, то, что нужно.

Я не хочу говорить, что кампус плохой, просто смотрю на факты, это просто мое личное мнение.

З.Ы. И зачем такой большой прелоадер?!
И оба проекта не смогли отправить мне е-мейл на подтверждение :)
для кампуса было campus@devg.ru
Судя по логам — на вашем сервере (mail.zoneedit.com[216.75.30.240] ) не совсем корректно настроен DNS.
На другие почтовые сервера все доходит без проблем.
И раз уж от скриблеров тоже ничего не пришло — думается мне, что действительно что то с DNS на вашем сервере.
zoneedit — сервер-редиректор.
Странно, он обычные письма ходят нормально. Да и от проектов разных тоже. Но если удобно — можете переписать ящик на devgru@mail.ru
Ящик изменил, письмо с активацией повторно выслал, по логам — оно дошло. Насчет DNS еще раз проверю на нашем сервере.
странного мнения вы про Dojo — какое дело проекту, что в нем много чего, если это _НЕ_ загружается если явно не используется (через dojo.require)? Что будет, если завтра будете расширяться и того, что дает мутулс обычному сайту, мало для мощного веб-приложения? ;) а в Dojo есть все необходимое и чуточку из области почти фантастики и вкусностей :)
Мои ответы с пометкой «Campus:»

1. Расписания на кампусе выглядят в виде добавления событий, что неправильно.
Scribbler: редактирование расписаний вынесено в отдельную сущность сайта.
Campus: планируем доделать, у Вас действительно интерфейс для забивания расписания удобнее

2. Загружать можно файлы объемом не более 30Мб, а что делать если вдруг нужно выложить видео-лекцию?
Scribbler: рабочий стол.
Campus: Нужно будет просто нам об этом сказать, пока никто не жаловался. Ограничение выставлено искусственно.

3. Wiki-учебник ведет на какой то сайт letopisi.ru, вот этого я не понимаю, зачем, лучше было бы убрать этот пункт, до тех пор пока не запрогали что то внутри проекта.
Scribbler: коллективная работа с документами есть, что будет потом не могу сказать, но будет круто.
Campus: А зачем изобретать велосипед? letopisi.ru — тоже наш проект, а Wiki — удобная и привычная всем среда для коллективного творчества. А я могу рассказать, что мы, когда дойдут руки, наверное интегрируемся с Google Apps, но востребованность этой фичи пока минимальная. Мы обычно планируем функционал исходя из этого критерия.

4. На сайте есть что нибудь повесомей кампусов (сообществ)?
Scribbler: Основная еденица — группа, сообщеста — круг людей по интересам.
Campus: Весомее?? Не понял вопрос. А что у Вас тяжелее — группа или сообщество? У нас есть учебные заведения, например.

5. Как мне отследить активность друзей?
Scribbler: Лента активности
Campus: Тоже. «Что нового»

6. Какова миссия проекта campus.ru, создавать кампусы?
Scribbler: помочь студенту в учебе, в плане учебы
Campus: помощь в построении карьеры, начиная со школьной скамьи. Я же говорил, что мы на разных полях играем.

7. Работа — это джоб сервис или ссылки на сайты с работой?
Scribbler: будет джоб сервис.
Campus: можно сказать что пока ссылки с на партнерский сайт. Тоже когда-нибудь доведем до ума, если будет потребность.

В общем архитектура сайта, наверно, и отличная, но я не понимаю, какова цель проекта.
Campus: Спасибо, см. п.6

Был такой проект studbox.ru, но он почему-то теперь закрыт, решал больше задач, чем в данный момент campus.ru, надеюсь, со временем функционал пополнится.
Campus: конечно! но действуем мы не по принципу чтобы сделать максимальное кол-во фич, а по принципу — делаем то, что требуется для достижения бизнес-задачи в данный момент времени (agile)

Java, конечно, тоже хорошо, тоже думали начинать программировать на этом языке, но если очень сильно постараться, то можно найти хороших PHP-программистов, что облегчит разработку и поддержку проекта.
Campus: конечно можно, ведь язык — это просто инструмент, главное — профессионализм команды. И на бейсике, я уверен, можно очень неплохой код писать.

по поводу Dojo, благодаря тому, что в нем дофигища всего готово, он тяжелый, потому стоило бы взглянуть в сторону mootools или jquery, и самим дописать, то, что нужно.
Campus: Тут у Вас какая-то подмена понятий получается. DOJO — фреймворк, jQuery и mootools — библиотеки. Почитайте обзоры. А самим дописывать, см. пословицу время=деньги.

Я не хочу говорить, что кампус плохой, просто смотрю на факты, это просто мое личное мнение.
Campus: Спасибо за Ваше мнение! Конечно, никому не надо говорить, что он плохой, живите в позитивной парадигме с менталитетом достаточности! ;)

З.Ы. И зачем такой большой прелоадер?!
Campus: Так получилось :)

Кто-нибудь из собравшихся Java-программистов может пособить в транспортировке Web Optimizer
habrahabr.ru/blogs/web_optimizator/
на какой-нибудь Java-фреймворк? Или придется писать сишный модуль к nginx?
т.е. Web Optimizer для java-приложений?..
многие фреймворки (например, GWT) делают многое из этого сами.

для остальных подойдёт просто servlet filter, который нужно будет подключить в web.xml оптимизируемого приложения

но не думаю, что для Java-приложений подобная оптимизация будет действительно эффективной — как правило они либо «правильные» с самого начала (пишут опытные люди), либо сильно «испорчены» тяжеловесными фреймворками вроде Seam.

Опять же, если перед Tomcat'ом поставить Apache/AJP13, то часть apache-оптимизаций может сработать сразу
спасибо за развернутый ответ. Но некоторые вещи (например, CSS Sprites) там явно не проработаны. Советуете обратиться к разработчикам напрямую с предложением «портировать» технологию?
Если речь идёт о фреймворке типа tapestry то CSS sprites к джаве никак не привязан — там можно как угодно писать css и раскидывать картинки, так что никакой java-специфики, как я понимаю, там нет.
Было бы просто замечательно, если форма регистрации работала в Опере.
Я тоже, кстати не понял закос на MS Internet Explorer 7 и Mozilla Firefox 3. Куда Опера делась?
Согласен. Фраза «Рекомендуем использовать браузеры MS Internet Explorer 7 или Mozilla Firefox 3» отпугивает бывалых Опероводов и новомодных Хромоводов.
Да, виноваты. Мы сейчас работаем над немного облегченной версткой сайта, она в итоге будет работать и с Оперой, и с Хромом. Выкатим к началу мая :)
Так как все-таки правильно: Creative Media или Cretive Media?
Евгений Ваганович! Не признал вас в гриме!
Creative Media, а вообще — ООО «Креатив Медиа» :)
тогда несколько странно, что ваш блог называется «Блог компании Cretive Media».
А вот просто интересно, в свете открытия Google AppEngine 4 Java с какими усилиями можно этот проектик пульнуть на google-вский клауд?
Навскидку больших проблем с этим не вижу, но код Hibernate скорее всего придется переделывать под JPA. А вообще, Tapestry 5 там работает tapestry.ganshane.com/
Дизайн отличный. По сравнению с тем же incampus.ru, этот — просто божественный.
Спасибо! :) Хотя, если честно, с объемом мы немного переборщили…
Буду признателен, если дадите конструктивную критическую оценку и рекомендации. Собственно, затем я сюда и пришел :)
форма регистрации:
показалась длинной
мой адблок блокировал аяксовый запрос, suggest названия вуза вроде
проверка свободности логина должна быть при его вводе, а не где-то в заднице

рабочий стол:
слишком много блоков на «рабочем столе», какая-та глупая тень у них и слишком большие промежутки между ними
слишком большие заголовки
зачем нужно было делать пункты меню «мои ....» жирным?
анимированная реклама — ппц
юзерпики по умолчанию не понравились
в верхнем меню есть галочки, но меню не выпадают
«Профиль заполнен на», непонятная тень у чисел с процентами

не нашел хелпа
Спасибо за мнение, порадую дизайнера :)
пожалуйста, если понадобится еще помощь, пишите в асечку
Campus тяжелый. Грузится с тормозами, это Вам не контакт. Но вещь прикольная :)
А у меня загрузился примерно в два раза быстрее чем вк.
Да, верстку сейчас доводим до ума, из-за теней и округлостей в CSS много expressions и браузер заметно подтормаживает. С дизайном немного перестарались :)
У вас домен через 17 дней заканчивается…
Спасибо! :) Там у нас должно автопродление стоять.
Конечно! Все продумано, пока не поздно — занимайте красивые ники ;)
Статья интересная и полезная — за неё спасибо, но меня всегда удивляли проекты, которые, не успев ничего мне предложить — уже требуют регистрацию. Я защёл на главную страницу вашего кампуса и вижу надписи «Общайся с друзьями, не покидая сайт, Твои фото-, видео-, и аудиогалереи.» и конечно же дико заинтересовался т.к. нигде в интернете этого больше не встречал!!! Конечно же, только у вас можно фотки выложить и, не покидая сайт, кому-то написать…
Покажите мне хоть что-то для начала, заинтересуйте меня, заинтригуйте хотя бы и тогда я, возможно, зарегистрируюсь и даже, возможно, вернусь на ваш ресурс… а так — я его просто закрыл.
Во-во…
# Обменивайся
учебными материалами
# Не пропускай
события! Учебные
или личные.
# Общайся с друзьями,
не покидая сайт.
# Ищи работу
по специальности.
# Твои фото-, видео-,
и аудиогалереи.

Было-бы разумно сделать ссылками на какие-нибудь демки хотябы… А так только раздражает что пытаешься по ним тыкать а они не реагируют(
На почту уже минут 15 ничего не приходит. Это нормально?
такая бага и у меня была. Просто попробовал зайти под логином, который в регистрации указал — пустило. Не очень стабильно работает рассылка почты. у меня была проблема — не приходили оповещения об обновлениях в кампусах. потом начали приходить. теперь опять не приходят
Извините, позвольте, пожалуйста, мне использовать пароли длиннее 16 символов и состоящие из любых символов, а не только латинских букв и цифр.
Допустим: gr*(6Rjhoi*&$%@_hto3&$%a.
Да, я параноик.
Кстати, это жутчайшее ограничение ИМХО вызвано тем, что Ваш пароль там используется не только для сравнения с тем, что Вы вводите при логине, но и ещё для чего-то, что не понимает нелатинских букв и цифр. Ну и хранятся пароли у них очевидно в открытом виде, а не в хеше.

А ещё жутко вымораживает ограничение длины логина странными минимумами и максимумами, основанными по всей видимости на том, что у авторов ник не слишком длинный и не слишком короткий.
Пароли у нас хранятся хешами, а ограничения такие, связаны с тем, что пароль действительно используеться для других целей — он передается календарному серверу при регистрации, где так же хранится в хеше.
Ограничение логина так же из-за сервисов, где он используется (фотохостинг, файловый хостинг, календарный сервер и т.д).
На какую планируемую нагрузку и какое количество серверов вы расчитываете, если не секрет?
Мы можем горизонтально масштабироваться без остановки сервиса по мере необходимости.
Я немного не про это. Перефразирую: сколько по вашему мнению вы сможете раздать с этих трех серверов (по одному на морду, app и базку), и во что в первую очередь упретесь?

>Мы можем горизонтально масштабироваться без остановки сервиса по мере необходимости.
Вы пробовали? ;)
На вскидку — 160 запросов/сек. Подробнее см. выше. В первую очередь упремся в сервер приложений.
Пробовали, конечно.
Без яваскрипта регистрация показывает только крутящийся до бесконечности круг. Не нра ((
UFO just landed and posted this here
огромный прелоадер угнетает )
Замечательная компания — «Кретив Медиа»
PS Название блога.
UFO just landed and posted this here
У нас клиент (приложение) спрашивает сиквенс у pgpool'а.
т.е. у нас нет, к примеру, запросов, выполняемых на сервере, которые меняют сиквенс.
UFO just landed and posted this here
Нет, не происходит.
На странице Пользовательское соглашение нижняя ссылка © CreativeMedia, 2008 ведет на кампус, а не на сайт компании
Очень интересный обзор архитектуры.

Не могли бы вы объяснить откуда эти данные, и как вы это проверяли?

Опыт показывает, что JVM эффективно работает с объемами памяти до 2 Гб, с учетом рекомендации, говорящей, что на каждый экземпляр JVM на сервере должно приходиться, по меньшей мере, два ядра процессора.

Это рекомендации по развертыванию компании BEA для серверов Weblogic. Они действительно имеют место быть, проверено высоконагрузочными проектами, успешно сделанными для Вымпелкома. Хотя, на практике все, конечно, индивидуально, и подходит это не для всех приложений, но для большинства web, с которыми я встречался — да. Если увеличивать, например, объем памяти, то начинались сложности со сборщиком мусора. Поскольку для серверов Tomcat подобных рекомендаций я не нашел, то применил те, что знал для weblogic :)
Я правильно понимаю, что у пользователей без джаваскрипта сайт работать не будет?
Да, не будет :( graceful degradation у нас по ряду причин не поддержан
критинская регистрация, сходу не получилось зарегаться (то логин больше 5 символов, а чё блин не 20? то проверка на уникальность логина после всех(!) шагов), больше на этот сайт ни ногой. Увольте придурков, которые как бы занимались «юзабилити»
Ффф.

Как уже говорилось выше — 279к 1!!! файл css — это жестоко :(
Общий вес стартовой страницы почти 1мб — это чересчур для того, что на ней есть. Оно конечно закешируется, но все же…

У меня пропадет желание регистрироваться в ожидании стартовой страницы.

Вынесите загрузку javascript и css в другое место.

P.S. вот так и появляются легенды о тормозах Java веб-приложений.
Прелоадер, мне кажеться, мог бы весьма меньше быть.
Клёва, клёва — tapestry 5 — гуд :) А что у вас со Spring Security, что вам там не подошло с ACL на доменах? Тут делаю целый стек с Tapestry5, в том числе буду использовать JSecurity (Ki) заместо Spring Security. Думаю через Hibernate Event'ы делать перехват операций и проверять права к объектам. А у вас как сделано?
Если в двух словах, то нам не хватило возможности прозрачно определять права конкретного пользователя для работы с конкретным объектом предметной области. Т.е. описывать не только возможность доступа к объекту (ресурсу), но еще и типы операций, которые с этим объектом можно делать. Все это хотелось реализовать без «сквозной» логики в программном коде. Об этом скоро напишем отдельную статью. У нас это сделано на уровне Tapestry IoC, через аннотации.
Сергей, еще вопрос: если я правильно понял, то у Вас по сути большая часть Java EE (Jms, Tomcat, JPA на Hibernate), но без самого j2ee :)

Насколько обоснованно было бы использовать Java EE в Вашем случае, как считаете?
Вопрос как-то странно звучит :) Что значит «использовать Java EE» в Вашем понимании? )
Я предполагаю, что есть как минимум «Ынтырпрайз» бины и есть контейнер для них (JBoss, WebSphere), в который входит составной частью контейнер сервлетов. EJB-контейнер обеспечивает различные сервисы, в том числе и JPA, и JMS, и JAAS.

У вас есть Tomcat, который контейнер сервлетов, есть JMS и Hibernate. В тексте я заметил, что вы упоминали авторизацию (которая всяко имеет отношение к JAAS). Хотел узнать, не складываются ли эти вещи в Java EE :)

Сильно не пинайте, я недавно в Java EE, вот и стараюсь разобраться :)
Я не автор статьи, извините :)
Поэтому я и задавал вопрос Сергею :)
Я просто прокомментировал что он странно звучит :)
Я совершенно без претензий к Вам :)
Да, можно и так сказать. Я бы сказал, что мы используем некоторые элементы стека JEE, но эти элементы достаточно легковесны (Сервлетный контейнер, а не полноценный J2EE-сервер. Легковесный ActiveMQ, с простыми JMS-клиентами на стороне приложения, а не MDB. Hibernate, а не полноценную реализацию EJB). Главным оправданием использования является то, что все подходы к построению архитектуры системы мы смогли реализовать с помощью готовых, надежных и бесплатных решений, велосипед изобретать не пришлось, сэкономили массу времени.

Использовать «классический» стек JEE (JSF+EJB) мы изначально не стали, из соображений плохого разделения верстки и презентационной логики, отсутствия IoC, да и, что греха таить, из соображений производительности. Tapestry 5 — ощутимо быстрее и менее ресурсоемка чем JSF. См. производительность Tapestry vs Seam.
Понятно, спасибо за пояснения.
JavaEE — это всего лишь спецификации. Кстати, их гораздо больше, чем JMS, JPA и JSP. Сервер JavaEE — это сервер, который реализует эти спецификации. Например если взять Apache Geronimo, то внутри вы увидите тот же Tomcat в качестве веб-контейнера. Плюс кучу всего в довесок. Реально из этой кучи нужны два-три сервиса, все остальное будет жрать память и тратить время при загрузке. Поэтому проще взять отдельно веб-контейнер, отдельно JMS, кинуть в classpath Хибернейт, JDBC-драйвер для постгреса, Спринг и прочие нужности, и запустить.

П.С. Spring Security не имеет отношения к JAAS. Spring Serurity может использовать JAAS.
Сергей, спасибо большое за статью.

На странице «Активация аккаунта» заголовок «Восстановление пароля» :)
Спасибо всем огромное за участие и за то, что поделились своими мыслями. По поводу замечаний — мы практически все про себя знаем, и все эти недостатки для нас не новость, мы работаем над их исправлениями. Все раздражители скоро устраним. Задача статьи, конечно, была не показать совершенство текущей реализации, а показать тот базовый фундамент (архитектуру), который мы заложили на светлое будущее.

P.S. Давайте делиться мыслями, дружить, осознавая, что мы не конкуренты — воздуха и интернета на всех хватит! :)
>> руководство поддержало решение «сразу делать хорошо и надолго»

Думаю, что с таким подходом будущее окажется действительно светлым
Большое спасибо за статью. Перезалейте, пожалуйста картинки — не отображаются.
Диаграмку бы кликабельной, что бы в читаемом состоянии посмотреть
Не могли бы вы поделиться опытом использования XWiki, кажется вы рассматривали на первом этапе в качестве Вики движка для проекта. Чем эта история закончилась?
насколько я понял, у вас 64х битные фри стоят, как на них жава себя ведет?
как-то пытался сетапить вовзу на 64х битную фрю, намучался, в итоге падучее оказалось, в интернетах пишут, что жава на фре плоха, а на 64х битной фре — еще хуже
последние комментраии от автора в были опубликованы в сентябре '09.
сейчас — октябрь '11

проект — «все»?
Sign up to leave a comment.