Но на самом деле что я про лайфрей и лайфрей. Как давний клиент Райфа могу сказать что новый кабинет это огромный прыжок вперед! Приятно видеть что к его разработке подходили с умом!
У нас был как раз опыт, когда компании делали сначала B2C сами, но потом переходили на портал. Можно самим разработать удобные инструменты работы с продуктами (и такие инструменты никакой портал из коробки не даст — тут в любом случае придется делать) — но потом приходит маркетинг и говорит «А вот тут я хочу разместить банер, а еще — добавьте здесь новую страницу с промо-контентом». Понятно что при правильных инструментах разработки и прямых руках это разрабатывается/добавляется в проект за пару часов — но это все равно разработка — соответственно появляется куча шагов (проработка тз, постановка задачи, сама разработка, деплой и тестирование на несколько сред и пр.) — а портал со встроенными средствами управления контента дает возможность делать это средствами «администрирования» — не привлекая разработку.
Ну и, учитывая что можно делать разработку и внедрение каждого «инструмента» отдельно — по сути дела реализуется паттерн «микросервисов» — но с точки зрения UI — когда, например, обновление инструмента работы с депозитами можно проводить не затрагивая все другие инструменты.
Про пример «претензии» на дизайн и высокой нагрузки — из того что доступно в паблике — www.yota.ru
Ну зря вы так про Liferay. Система сложная — но при правильном подходе может многое. Просто как и с любой сложной системой ее надо «уметь готовить» (порог входа по моим ощущениям минимум 6 месяцев). Жаль когда изучали идею про Liferay до нас не дошли — мы внедряем Liferay уже 8 лет — и есть примеры и высоконагруженных систем (с аптаймом 100%) и примеры в финсекторе (банки, страховые) — разные примеры бы показали.
Почему у вас возникла мысль про Liferay? Возможно потому что он активно используется в Райфе в Восточной Европе (с ходу о ком знаю и кого можно нарыть в публичном доступе — Венгрия, Чехия, Хорватия) — видимо оттуда ветром и принесло идею.
Самая печальная новость. Это что же, теперь все, кто не на томкате, должны энтерпрайз лицензию покупать?
Те кто не на томкате, wildfly и глассфише. Считается что если у вас есть деньги на WebSphere/WebLogic — то глупо экономить на «спичках» (лиценизциях на Liferay). Аналогично с базами — если есть деньги на Oracle — то ожидается что и на портал найдутся.
Кластеризация предполагает постоянную синхронизацию по данным. А это сразу же бутылочное горлышко — горизонтально не отмасштабируешься.
Понял, согласен! Как вы и писали выше — Liferay использует ehcache и как только возникает кластер — встает задача синхронизации кешей на нодах. Ну и 100 нод щелчком мыши не запустишь — сразу уткнешься в вопросы синхронизации. В платной версии есть плагин который оптимизирует синхронизацию данных между нодами — но все равно на больших кластерах это будет бутылочное корлышко.
Про масштабируемость: у вас получается все-таки чуть-чуть другой подход чем у нас — у вас liferay — чисто фронт-енд (вся бизнес-логика на back-end серверах) и управлением контента самого портала (страницы, конфигурация портлетов, контент и пр.) как понимаю занимаются сами программисты (если я правильно понял — у вас «версия» — это набор версий портлетов плюс определенная конфигурация- набор страниц, размещения портлетов, контенты) — соотвественно все собирает команда разработки, ставит — и потом это стоит и не меняется. Правильно понял? Тогда да — такой подход «независимых» порталов у вас сработает.
В нашем случае мы даем в первую очередь набор инструментов (портлеты) — проводим первичную установку, настройку — а дальше уже админы и бизнес-пользователи клиента по необходимости управляют всем этим. В этом случае — сам Liferay настраивается в кластер (и тут не со всем понял что имеется в виду под «масштабируется слабо») — и да — все сервера Liferay используют одну базу (дальше если требуется — база кластеризуется своими средствами).
Про поддержку веб-серверов — да, почти так — может работать на любом сервере — но есть небольшие нюансы. При старте портал в частности определяет тип сервера, определяет поведение при хот-деплое и прочее. Вот поддержку нюансов для коммерческих серверов из Liferay CE 7 и удалили.
Аналогично с базами данных — да, Liferay использует Hibernate — но не все что поддерживает Hibernate — поддерживается в Liferay — так как для каждой базы есть свои небольшие «допилы». Их тоже удалили.
Хотя это лукавство — код из истории github не удалишь — так что все легко возвращается. Другое дело что развитие этой поддержки будет уже только в платной версии.
Liferay 6.x поддерживает кластеризацию — проблем нет. Есть возможность выноса контента на CDN (но для нормальной работы требует допила). Небольшим допилом можно реализовать кеширование портлетов для анонимных пользователей.
То есть из коробки поддерживается кластеризация и базовые вещи для поддержки высокой нагрузки — но не всегда оптимально — и там где я писал про «допилы» — это то что мы сами «наработали» за годы внедрения.
XML есть в PortletProperties/PortalProperties. И в контенте (например контент JournalArticle). Так же через XML хранятся локализуемые строки (например заголовок страницы будет идти в XML так как это локализуемый атрибут). В целом все (хотя если мог пропустить что-то важное).
Хотя стоп — Dynamic Data Mapping (кастомные формы и доп поля к веб-контенам и документам) — там тоже все в XML — тут да — проблема — это делает невозможным использовать эти формы для чего-то более-менее серьезного.
Но в целом база Liferay вполне себе реляционная :)
По поводу стоимости — смотря с чем сравнивать. Если с WebSphere или SharePoint — то Liferay очень и очень дешев.
Кстати — по моим наблюдениям бесплатность зачастую играет злую шутку с Liferay — люди его берут — раз бесплатный — но не учитывают что это достаточно сложный продукт — и что это на самом деле не что-то готовое — а конструктор — и что потом надо очень серьезно вложиться чтобы из этого конструктора что-то собрать. А особенно учитывая что JEE разработчики ( а тем более с опытом Liferay) стоят намного дороще PHP + какой-нибудь Битрикс — то «бесплатность» оборачивается для клиента высокими костами — и если он не был к этому готов — то проект в итоге вообще не достигает цели а клиент убеждается что «г… ваш этот Liferay».
Про замечания — Liferay не идеален — вопрос в том — для чего его использовать.
Если нужен просто сайт (просто CMS) — ну да, можно использовать Liferay, можно его фичи именно в плане построения сайтов (версионирование и варианты страниц, remote staging, согласование публикации контента, asset publisher и прочее и прочее). Но, уверен что тут есть и другие решения, скорей всего более удобные и более дешевые.
Внутренний портал… ну скажем так — если речь идет о сотнях сотрудников — то 1С Битрикс в руки и вперед.
Реализовать приложение которое решает какую-то конкретную задачу? Зачастую проще сделать сделать самим с нуля (благо framework-ов сейчас много). Не хотите с нуля — берем туже Cuba Platform и вперед — куча всего что есть «из коробки».
Из нашего опыта — Liferay имеет смысл:
1. Когда круг решаемых задач заранее неопределен и может быстро меняться. Тут Liferay реализовал по сути дела модель микросервисов — только на стороне UI — можно реализовать набор инструментов (сервисов — портлетов) и дальше на ходу комбинировать их в том виде в котором это требуется. И тут нет зачастую задач release management-а конфигурации о которых говорилось выше и решения для которых у Liferay нет — по сути дела мы имеет конструктор который уже средствами content manager-а собирается в ту или иную конфигурацию (грубо говоря — если вы делаете просто как-йто сайт — вы же не будете делать релиз для каждой новой новости? это же просто контент — так и тут — страницы и размещение портлетов — это просто «контент»).
2. B2B платформы — в отличие от той же CUBA в Liferay можно завести пользователей разных организаций, каждому пользователю в зависимости от типа организации и его роли настроить свое рабочее простарнство (из тех кубиков-микросервисов-портлетов что есть в заготовке) и дать всем возможность совместно работать.
Опять-таки — если процесс B2B взаимодействия, набор ролей и типов организаций определен заранее — можно написать и что-то свое, с нуля. Но если это заранее не определено (партнерский портал — где сегодня мы обмениваемся одним типом информации — а завтра будет другой) — то каждый раз переколбашивать приложение будет уже накладно.
И тут я альтернатив для Liferay не вижу (если говорить про стек технологий JEE) Но я не являюсь ярым фанатиком — буду благодарен за указание на продукты которые так же могут решать данные задачи.
Не совсем так: все данные Liferay хранит в базе в реляционной модели. Вне базы (в папке /data) хранятся только:
* Бинарный контент файлов (и именно его можно перенести в хранилище JCR — что на самом деле лишено смысла)
* Поисковые индексы lucene (в случае если не используется solr).
Так что само хранение данных — оно вполне реляционное.
LAR-файл с «непонятной структурой» о котором вы говорили выше — это только формат переноса данных между серверами.
По поводу мержа конфигурации — решения нет. Обычно как у нас устроено:
1. Разработка портлетов идет в отдельных фиче-бранчах — по мере готовности сливается в мастер — тут ничего, что отличалось бы обычной разработки
2. CI сервер с автоматическим деплоем на dev-среду. Там разработчик, если требуется проводит необходимую конфигурацию (документируя ее) — предварительное тестрование.
3. По мере готовности перенос на qa-env — там настройка уже осуществляется одним человеком (вручную)
4. По мере готовности так же в ручном режиме перенос на прод (опять-таки перенос настройки вручную).
Ну и бекапы.
LAR-файлы, как обсуждали выше — к сожалению не гарантируют 100% перенос — в итоге если их использовать — то после переноса LAR-ником все равно надо пройти и ручками все проверить что правильно перенеслось — проще сразу делать перенос конфигурации руками.
Вы чуть-чуть не правы. JCR — один из возможных способов хранения контента файлов (наряду с собственным файловых хранилищем, базой и Amazon S3). Причем JackRabbit (как реализация JCR) используется только для контентов файлов из портлета Documents & Library. Все остальные Asset-ы (веб-контент и прочее) хранится в базе.
В нашей практике мы JCR не использовали ни разу (если честно — просто не понимаю профита). Из общения с IT-специалистами одной из компаний, где был внедрен BackBase — который тоже базируется на JCR — люди огребли с ним бооооольшие проблемы по производительности.
Поправочка — JUG.ru уже «спрыгнул» с Liferay (для нас, как компании которая занимается внедрением Liferay — факт печальный — но увы и ах).
На предмет шаблонизации — в Liferay 6.2 есть штатное средство — Application Display Templates — позволяет задать для портлетов шаблоны (поддерживается velocity & freemaker — это конечно не Google Closure Templates — но зато штатное и из коробки).
Вопрос хранения конфигурации — да, отдельная больная тема — тут вы совершенно правы. Как результат — версионность можно добиться только полным бекапом (и всех вар-ников, и базы, и папки data). Поведение импорта-экспорта (а так же stage-инга — так как он основан на том же импорте-экспорте) как вы правильно заметили совершенно непредсказуемо (особенно если вы используете бесплатную версию CE)
Ну и про «черную магию с подменой класслоадеров» — отдельные аплодисменты :) Только тот, кто до конца раскопал, как работает BeanFactoryLocator — тот поймет. Успокаивает одно — в 7-ой версии с переходом на OSGI это шаманство должно уйти в прошлое.
на самом деле WSO2 DSS умеет и REST (если вы это имели в виду). Но как бы то ни было — если речь идет об интеграции информационных систем внутри компании — то SOAP никто не отменял и я думаю вряд ли в ближайшее время отменит.
Коллега — поддерживаю вас в ваших опасениях — сам не раз сталкивался когда «покупались» на красивые маркетинговое демки и потом огребали по полной. Но тот же Liferay я выбирал в свое время именно как программист, и за практически 7 лет в выборе не разочаровался. Да — есть минусы и органичения. Да — есть моменты когда Liferay просто выбешивает — но идеальных решений не бывает — всегда идет компромис между плюсами и минусами — и для меня плюсы Liferay перевешивают его минусы.
Спасибо за jhipster — я как раз хотел посмотреть что есть сейчас из высокоуровневых framework-ов способных решать близкие по сложности задачи (в списке были Entando и Cuba, добавлю еще и jhipster).
Но — это все таки не совсем то. Просто пример — модель безопасности. Да — есть Spring Security — но в плане ролевой безопасности его возможности по реализации (насколько я помню) ограничены. Есть задача — назначать на любые сущности разрешение для любой роли на «Просмотр» (ну и другие разрешения). Возникают объекты (в разных системах они называются по разному — но смысл примерно один и тот же): User, Role, Resource, Permission — и соотвественно возможность назначать на определенный Resource Permission «View» для определенной Role.
А теперь ситуация — таблица с миллионами записей (Resource-ы) и надо для конкретного пользователя User который входит в несколько Role-ей показать таблицу (с шагом записей 20 штук) только тех объектов которые он может смотреть…
jhispter даст нам решение этой задачи? Сомневаюсь. Писать самому модель безопасности — можно. Но я например наблюдаю прогресс в реализации модели в Liferay и вижу что если 6 лет назад там делалась выборка из базы и фильтрация средствами Java — то сейчас уже формируются 10-ти этажные sql-запросы, но фильтрация объектов с учетом прав доступа осуществляется на уровне базы с соотвествующей производительностью. И вот сколько времени займет такое реализовывать самому — я даже затрудняюсь ответить.
Потому — для каждой задачи — свой инструмент. Где-то да — проще самому разработать систему (не с нуля — а используя в качестве отправной точки какой-то framework или стек — будь то jhispter, entando, cuba и так далее — список можно продолжить) — а где-то (для более сложных задач) проще все-таки взять готовый продукт и допиливать его (благо open source и исходники есть).
Да — приложение достаточно сложное. По моим прикидкам время «входа» — до полугода. 300 метров — ну так это приложение Enterprise уровня. Сравните с другими лидерами гантера (SharePoint, WebSphere Portal, SAP, Oracle) — те еще больше и монструозней — на их фоне Liferay супер легкость и простота.
А каких решений не опасаетесь?
Ну и — не знаю что у вас произошло с Альфреской — но были негативные отзывы о Liferay. Мне кажется общая проблема в следующем — системы (что Alfresco, что Liferay) достаточно сложные — для реализации более-менее сложных задач требуется опыт. Зачастую же складывается как — берут (потому что бесплатно) — сажают админа или unior-разработчика — мол «поковыряйся — что там и как», потом кое-как решают поставленную задачу — она нифига не решается, все работает плохо и криво, а итоге решают что продукт «отстой» и все выкидывают.
Мне конечно обидно такое наблюдать — так как проблема в данном случае не в продукте — а в умении с ним обращаться — но такие ситуации встречал не раз.
Ну и еще про сложность — каждый инструмент для своего типа задач. Я когда с клиентом встречаюсь — первым делом выясняю зачем им портал, какие у них стоят задачи — чтобы понять, а нужен ли им Liferay в принципе.
Если им надо промо сайт на 5 страниц — не нужен Liferay — любая CMS на PHP сделает его проще и быстрее чем это будет на Liferay.
Если им надо чисто внутренний портал на 10-100 человек — не нужен Liferay — это будет дорого и неэффективно — есть более дешевые и простые решения
Если нужно реализовать какой-то процесс с тремя типами участников — не нужен Liferay — любой программист с прямыми руками напишет систему с требуемым функционалом с нуля или на базе top-level framework-а значительно быстрее.
Ну а если задача реально сложная — очевидно что для ее решения требуются сложные системы.
Я старался быть объективен — но действительно это может не всегда получаться.
Liferay — сложен так как реализует сложный функционал. То что точно ему в минус — это что «из коробки» идет куча мусора — в ядро системы входит куча портлетов (функционала) который может быть и не нужен. И тут я как раз и отметил — что вариант использования JBoss в том случае если требуется чистый Portlet Container — без лишнего функционала.
В очереди — я не планирую на этом останавливаться, но из списка — IBM WebSphere портал — не open-source, Jetspeed-2 и Pluto еще большие «поделки» чем JBoss (по крайней мере на то время когда я их смотрел — может конечно что-то изменилось за последние пару лет)
Как я понял — они его не покупали — а развивали достаточно давно — но сил развить что бы из проекта это превратилось в ПРОДУКТ (ценный сам по себе — без привязки к производителю и его стеку продуктов) уже не хватило.
Но на самом деле что я про лайфрей и лайфрей. Как давний клиент Райфа могу сказать что новый кабинет это огромный прыжок вперед! Приятно видеть что к его разработке подходили с умом!
Ну и, учитывая что можно делать разработку и внедрение каждого «инструмента» отдельно — по сути дела реализуется паттерн «микросервисов» — но с точки зрения UI — когда, например, обновление инструмента работы с депозитами можно проводить не затрагивая все другие инструменты.
Про пример «претензии» на дизайн и высокой нагрузки — из того что доступно в паблике — www.yota.ru
Почему у вас возникла мысль про Liferay? Возможно потому что он активно используется в Райфе в Восточной Европе (с ходу о ком знаю и кого можно нарыть в публичном доступе — Венгрия, Чехия, Хорватия) — видимо оттуда ветром и принесло идею.
Те кто не на томкате, wildfly и глассфише. Считается что если у вас есть деньги на WebSphere/WebLogic — то глупо экономить на «спичках» (лиценизциях на Liferay). Аналогично с базами — если есть деньги на Oracle — то ожидается что и на портал найдутся.
Понял, согласен! Как вы и писали выше — Liferay использует ehcache и как только возникает кластер — встает задача синхронизации кешей на нодах. Ну и 100 нод щелчком мыши не запустишь — сразу уткнешься в вопросы синхронизации. В платной версии есть плагин который оптимизирует синхронизацию данных между нодами — но все равно на больших кластерах это будет бутылочное корлышко.
В нашем случае мы даем в первую очередь набор инструментов (портлеты) — проводим первичную установку, настройку — а дальше уже админы и бизнес-пользователи клиента по необходимости управляют всем этим. В этом случае — сам Liferay настраивается в кластер (и тут не со всем понял что имеется в виду под «масштабируется слабо») — и да — все сервера Liferay используют одну базу (дальше если требуется — база кластеризуется своими средствами).
Про поддержку веб-серверов — да, почти так — может работать на любом сервере — но есть небольшие нюансы. При старте портал в частности определяет тип сервера, определяет поведение при хот-деплое и прочее. Вот поддержку нюансов для коммерческих серверов из Liferay CE 7 и удалили.
Аналогично с базами данных — да, Liferay использует Hibernate — но не все что поддерживает Hibernate — поддерживается в Liferay — так как для каждой базы есть свои небольшие «допилы». Их тоже удалили.
Хотя это лукавство — код из истории github не удалишь — так что все легко возвращается. Другое дело что развитие этой поддержки будет уже только в платной версии.
То есть из коробки поддерживается кластеризация и базовые вещи для поддержки высокой нагрузки — но не всегда оптимально — и там где я писал про «допилы» — это то что мы сами «наработали» за годы внедрения.
А вот с Liferay 7 (новой версией) все немного хуже — из бесплатной версии убрали поддержку кластеризации (тут подробней: http://www.emdev.ru/-/ogranicenia-liferay-7-0-ce
Хотя стоп — Dynamic Data Mapping (кастомные формы и доп поля к веб-контенам и документам) — там тоже все в XML — тут да — проблема — это делает невозможным использовать эти формы для чего-то более-менее серьезного.
Но в целом база Liferay вполне себе реляционная :)
Кстати — по моим наблюдениям бесплатность зачастую играет злую шутку с Liferay — люди его берут — раз бесплатный — но не учитывают что это достаточно сложный продукт — и что это на самом деле не что-то готовое — а конструктор — и что потом надо очень серьезно вложиться чтобы из этого конструктора что-то собрать. А особенно учитывая что JEE разработчики ( а тем более с опытом Liferay) стоят намного дороще PHP + какой-нибудь Битрикс — то «бесплатность» оборачивается для клиента высокими костами — и если он не был к этому готов — то проект в итоге вообще не достигает цели а клиент убеждается что «г… ваш этот Liferay».
Про замечания — Liferay не идеален — вопрос в том — для чего его использовать.
Если нужен просто сайт (просто CMS) — ну да, можно использовать Liferay, можно его фичи именно в плане построения сайтов (версионирование и варианты страниц, remote staging, согласование публикации контента, asset publisher и прочее и прочее). Но, уверен что тут есть и другие решения, скорей всего более удобные и более дешевые.
Внутренний портал… ну скажем так — если речь идет о сотнях сотрудников — то 1С Битрикс в руки и вперед.
Реализовать приложение которое решает какую-то конкретную задачу? Зачастую проще сделать сделать самим с нуля (благо framework-ов сейчас много). Не хотите с нуля — берем туже Cuba Platform и вперед — куча всего что есть «из коробки».
Из нашего опыта — Liferay имеет смысл:
1. Когда круг решаемых задач заранее неопределен и может быстро меняться. Тут Liferay реализовал по сути дела модель микросервисов — только на стороне UI — можно реализовать набор инструментов (сервисов — портлетов) и дальше на ходу комбинировать их в том виде в котором это требуется. И тут нет зачастую задач release management-а конфигурации о которых говорилось выше и решения для которых у Liferay нет — по сути дела мы имеет конструктор который уже средствами content manager-а собирается в ту или иную конфигурацию (грубо говоря — если вы делаете просто как-йто сайт — вы же не будете делать релиз для каждой новой новости? это же просто контент — так и тут — страницы и размещение портлетов — это просто «контент»).
2. B2B платформы — в отличие от той же CUBA в Liferay можно завести пользователей разных организаций, каждому пользователю в зависимости от типа организации и его роли настроить свое рабочее простарнство (из тех кубиков-микросервисов-портлетов что есть в заготовке) и дать всем возможность совместно работать.
Опять-таки — если процесс B2B взаимодействия, набор ролей и типов организаций определен заранее — можно написать и что-то свое, с нуля. Но если это заранее не определено (партнерский портал — где сегодня мы обмениваемся одним типом информации — а завтра будет другой) — то каждый раз переколбашивать приложение будет уже накладно.
И тут я альтернатив для Liferay не вижу (если говорить про стек технологий JEE) Но я не являюсь ярым фанатиком — буду благодарен за указание на продукты которые так же могут решать данные задачи.
* Бинарный контент файлов (и именно его можно перенести в хранилище JCR — что на самом деле лишено смысла)
* Поисковые индексы lucene (в случае если не используется solr).
Так что само хранение данных — оно вполне реляционное.
LAR-файл с «непонятной структурой» о котором вы говорили выше — это только формат переноса данных между серверами.
По поводу мержа конфигурации — решения нет. Обычно как у нас устроено:
1. Разработка портлетов идет в отдельных фиче-бранчах — по мере готовности сливается в мастер — тут ничего, что отличалось бы обычной разработки
2. CI сервер с автоматическим деплоем на dev-среду. Там разработчик, если требуется проводит необходимую конфигурацию (документируя ее) — предварительное тестрование.
3. По мере готовности перенос на qa-env — там настройка уже осуществляется одним человеком (вручную)
4. По мере готовности так же в ручном режиме перенос на прод (опять-таки перенос настройки вручную).
Ну и бекапы.
LAR-файлы, как обсуждали выше — к сожалению не гарантируют 100% перенос — в итоге если их использовать — то после переноса LAR-ником все равно надо пройти и ручками все проверить что правильно перенеслось — проще сразу делать перенос конфигурации руками.
В нашей практике мы JCR не использовали ни разу (если честно — просто не понимаю профита). Из общения с IT-специалистами одной из компаний, где был внедрен BackBase — который тоже базируется на JCR — люди огребли с ним бооооольшие проблемы по производительности.
Поправочка — JUG.ru уже «спрыгнул» с Liferay (для нас, как компании которая занимается внедрением Liferay — факт печальный — но увы и ах).
На предмет шаблонизации — в Liferay 6.2 есть штатное средство — Application Display Templates — позволяет задать для портлетов шаблоны (поддерживается velocity & freemaker — это конечно не Google Closure Templates — но зато штатное и из коробки).
Вопрос хранения конфигурации — да, отдельная больная тема — тут вы совершенно правы. Как результат — версионность можно добиться только полным бекапом (и всех вар-ников, и базы, и папки data). Поведение импорта-экспорта (а так же stage-инга — так как он основан на том же импорте-экспорте) как вы правильно заметили совершенно непредсказуемо (особенно если вы используете бесплатную версию CE)
Ну и про «черную магию с подменой класслоадеров» — отдельные аплодисменты :) Только тот, кто до конца раскопал, как работает BeanFactoryLocator — тот поймет. Успокаивает одно — в 7-ой версии с переходом на OSGI это шаманство должно уйти в прошлое.
Спасибо за jhipster — я как раз хотел посмотреть что есть сейчас из высокоуровневых framework-ов способных решать близкие по сложности задачи (в списке были Entando и Cuba, добавлю еще и jhipster).
Но — это все таки не совсем то. Просто пример — модель безопасности. Да — есть Spring Security — но в плане ролевой безопасности его возможности по реализации (насколько я помню) ограничены. Есть задача — назначать на любые сущности разрешение для любой роли на «Просмотр» (ну и другие разрешения). Возникают объекты (в разных системах они называются по разному — но смысл примерно один и тот же): User, Role, Resource, Permission — и соотвественно возможность назначать на определенный Resource Permission «View» для определенной Role.
А теперь ситуация — таблица с миллионами записей (Resource-ы) и надо для конкретного пользователя User который входит в несколько Role-ей показать таблицу (с шагом записей 20 штук) только тех объектов которые он может смотреть…
jhispter даст нам решение этой задачи? Сомневаюсь. Писать самому модель безопасности — можно. Но я например наблюдаю прогресс в реализации модели в Liferay и вижу что если 6 лет назад там делалась выборка из базы и фильтрация средствами Java — то сейчас уже формируются 10-ти этажные sql-запросы, но фильтрация объектов с учетом прав доступа осуществляется на уровне базы с соотвествующей производительностью. И вот сколько времени займет такое реализовывать самому — я даже затрудняюсь ответить.
Потому — для каждой задачи — свой инструмент. Где-то да — проще самому разработать систему (не с нуля — а используя в качестве отправной точки какой-то framework или стек — будь то jhispter, entando, cuba и так далее — список можно продолжить) — а где-то (для более сложных задач) проще все-таки взять готовый продукт и допиливать его (благо open source и исходники есть).
Да — приложение достаточно сложное. По моим прикидкам время «входа» — до полугода. 300 метров — ну так это приложение Enterprise уровня. Сравните с другими лидерами гантера (SharePoint, WebSphere Portal, SAP, Oracle) — те еще больше и монструозней — на их фоне Liferay супер легкость и простота.
Документация — dev.liferay.com — сейчас вполне вменяемая. Форумы — www.liferay.com/community/forums/-/message_boards/recent-posts — практически нет постов без ответов.
Код — вполне вменяемый.
Ну и — не знаю что у вас произошло с Альфреской — но были негативные отзывы о Liferay. Мне кажется общая проблема в следующем — системы (что Alfresco, что Liferay) достаточно сложные — для реализации более-менее сложных задач требуется опыт. Зачастую же складывается как — берут (потому что бесплатно) — сажают админа или unior-разработчика — мол «поковыряйся — что там и как», потом кое-как решают поставленную задачу — она нифига не решается, все работает плохо и криво, а итоге решают что продукт «отстой» и все выкидывают.
Мне конечно обидно такое наблюдать — так как проблема в данном случае не в продукте — а в умении с ним обращаться — но такие ситуации встречал не раз.
Если им надо промо сайт на 5 страниц — не нужен Liferay — любая CMS на PHP сделает его проще и быстрее чем это будет на Liferay.
Если им надо чисто внутренний портал на 10-100 человек — не нужен Liferay — это будет дорого и неэффективно — есть более дешевые и простые решения
Если нужно реализовать какой-то процесс с тремя типами участников — не нужен Liferay — любой программист с прямыми руками напишет систему с требуемым функционалом с нуля или на базе top-level framework-а значительно быстрее.
Ну а если задача реально сложная — очевидно что для ее решения требуются сложные системы.
Liferay — сложен так как реализует сложный функционал. То что точно ему в минус — это что «из коробки» идет куча мусора — в ядро системы входит куча портлетов (функционала) который может быть и не нужен. И тут я как раз и отметил — что вариант использования JBoss в том случае если требуется чистый Portlet Container — без лишнего функционала.