Liferay::EXT

EXT Environment

основа Liferay это Spring, Hibernate и AXIS.
Spring управляет зависимостями и инекциями классов между модулями. он же управляет транзакциями, содержит конфигурацию различного рода кешей, пулов, источников данных
Hibernate управляет собственно данными
AXIS предоставляет доступ к данным через веб-сервисы
вокруг этих технлогий Liferay имеет надстройку из собственных классов, которая и является ESB Liferay. эта ESB, в свою очередь, спроектирована по принципу Service Oriented Architecture и разделена на три части:

1. Persistence Beans, которые являются ничем иным, как объектами Hibernate мэпинга
2. сервисами, реализующими логику доступа и управления данными
3. сервисами, обеспечивающими удаленный доступ к логике управления lанными

собеседования

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

Liferay::Basics

Liferay - Введение

Преамбула

С портальными контейнерами спецификации JSR-168 я столкнулся в 2006 году. Все было достаточно тривиально, клиент хотел портальное решение на Java и я был назначен найти наиболее подходящее. После рассмотрения JBoss Portal, Exo, Apache Jetspeed2, Apache Pluto я понял, что в мире порталов пока все еще довольно не просто и не тривиально. И когда я уже готовился с кровью отстаивать очень не быстрые сроки, мне попался Liferay тогда еще версии 3.6.5.
Этот портал, в отличие от братьев по спецификации, бодренько зашуршал из коробки и показал мне много всякого. Его и выбрали в качестве платформы.

Coffee'n'Code Kharkiv

Сформированна программа мероприятия, подробности на сайте.
Приходите, будет интересно

jQuery && WebKit based browsers

хозяйке на заметку, события document.ready и window.load в браузерах основанных на WebKit срабатывают раньше, чем будут загружены основные ресурсы. таким образом никак невозможно критически важные JavaScript функции, срабатывание которых запланированно на момент загрузки окна или DOM Document'а, помещать во внешние файлы.

господа Google-разработчики -- это таки баг

Spring Portlet MVC

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

Maven2::Part #5

Assembly plugin

несколько слов об assembly plugin. Maven предоставляет возможность формировать delivery package с помощью assembly plugin. стандартная документация описывает процесс создания конечного пакета в формате bin и src, как это обычно выглядит для всех продуктов Apache Software Foundation. однако, с помощью этого плагина можно формировать пакеты абсолютно произвольного формата. для этого понадобиться дескриптор assembly.xml, в котором с помощью тэгов включаются и исключаются необходимые артефакты и исходники, а с помощью тэгов -- артефакты зависимостей, необходимые в delivery package. все остальные тэги assembly.xml можно не использовать. с другой стороны, если delivery package соотвествует формату, принятому в Apache Software Foundation, можно использовать стандартные конфигурации assembly.xml, которые представлены на сайте Maven

Maven2::Part #4

Управление зависимостями (Dependency Management)

в первую очередь следует обратить внимание на стандратную документацию Maven. она довольпо подробно объясняет, как использовать механизм управления зависимостями. я хочу оставновится на некоторых моментах, которые могут быть не ясны из стандартной документации

Maven::Part #3

Multimodule projects

каждый pom.xml файл описывает build workflow для одного проекта, в конечной фазе которого мы имеем один артефакт установленный в локальный и удаленный репозитарий. однако Maven позволяет легко и удобно работать с многомодульными проектами. при этом задача управления зависимостями между внешними библиотеками и между модулями внтури проекта полностью решается самим Maven.

Maven2::Part #1

Maven build workflow

полный список фаз Maven build workflow можно найти в документации. за каждую фазу отвечает какой-нибудь плагин из группы org.apache.maven. каждый из плагинов, кроме цели по-умолчанию, как правило умеет еще много полезных вещей. поэтому даже для стандартных плагинов нужно и важно читать документацию. встраиваться в ту или иную фазу довольно просто

...
 <plugin>
   <groupId>com.mycompany.example</groupId>
   <artifactId>maven-touch-plugin</artifactId>
   <version>1.0</version>
   <executions>
     <execution>
       <phase>process-test-resources</phase>
       <goals>
         <goal>timestamp</goal>
       </goals>
     </execution>
   </executions>
 </plugin>
...

Важно: все кастомные цели вызываются в конце выполнения указанной фазы. т.е. если перед фазой package необходимо что-то сделать с ресурсами, то для этой цели фаза должна быть prerare-package, а не package

отдельно следует отметить фазы цикла package, install и deploy.
package -- фаза, когда происходит сборка артефакта. стандартные плагины, для сборки артефактов, входящие в поставку Maven, умеют собирать jar, war, ear, ejb, rar, shade. каждый из сборщиков умеет класть внутрь архива необходимые ресурсы и раскладывать их по необходимым местам автоматически.
install -- фаза, когда собранные на этапе package артефакты проекта устанавливаются в локальный репозитарий. плагин создает каталоги группы и версии, копирует в созданную структуру артефакт и генерирует необходимую метаинформацию
deploy -- фаза, когда проинсталлированные в локальный репозитарий артефакты, переносятся в удаленный репозитарий. тут важно отметить, что Maven следит за обновлениями удаленных репозитариев автоматически. так что для того, чтобы обновить какой-то модуль для удаленной команды, необходимо только задеплоить его в общий удаленные репозитарий.