java – Nikolay´s Technical Blog

Семинар “Java Portlets with Liferay and JSF”

Java, Software Design & Development No Responses »

сеп 262011

Българската Java потребителска група организира семинар на тема “Java Portlets with Liferay and JSF”.

Координати на събитието

Събитието ще се проведе на 29.09.2011 г от 19:00 до 21:00 в зала 325, на Факултет по математика и информатика към СУ “Св. Климент Охридски”.

Описание

JS Mashup с портлети

Портлетите представляват видимия и полезен за крайния потребител резултат от внедряването на Service Oriented Architecture (SOA). Те са технология, която дава възможност на бизнес организациите да осигурят повече функционалност, гъвкавост и възможност за персонализация за своите клиенти. С помощта на Web Services for Remote Portlets (WSRP) стандарта на OASIS за отдалечено публикуване на портлети става възможно бизнес услугите лесно да бъдат интегрирани в партньорски портали. Стандартът се ползва с подкрепата на големите доставчици на портални решения като Oracle^®, IBM^® и Microsoft^®.

Внедряването на централизирани уеб портали предлага редица предимства за бизнеса:

осигуряват входна точка за достъп за всички служители, партньори и клиенти
предлагат достъп до бизнес функционалността прозрачно и независимо от устройството и местоположението
порталите са гъвкави – те могат да съществуват под формата на B2E intra-nets, B2B extra-nets или B2C inter-nets
могат да бъдат комбинирани в портални мрежи, които обхващат цялата бизнес екосистема на организацията
понеже осигуряват „front end“ за различни уеб услуги, те позволяват лесно интегриране на хетерогенни съществуващи приложения и са отворени към бъдещето (future-proof).

В последните години Java портлетите станаха популярна технология, която позволява лесно споделяне и комбиниране на приложения от различни организации и индивиди в персонализиран уеб портал. Новият портлетно-базиран стил на разработка на уеб приложения дава възможност за създаване на по-разпределени, гъвкави и лесни за повторно използване компоненти, в сравнение с традиционните монолитни решения. Портлетните приложения типично се състоят от множество различни портлети, които могат да бъдат гъвкаво позиционирани върху уеб страницата и комуникират помежду си с използване на споделени параметри (shared parameters), събития (publish/subscribe events), съгласно Portlet Specification 2.0, или чрез JavaScript и AJAX (без презареждане на страницата).

Презентацията демонстрира разработката на портлети с Portlet 2.0 Specification (JSR-286) и портален сървър Liferay (http://www.liferay.com). Liferay е едно от водещите портални решения с отворен код, лидер в Gartner®’s Magic Quadrant for Horizontal Portals.

Включени са демонстрации на JSP, JSF и Spring портлети, Mashups с използване на Google Maps, както и новости при разработката на портлети с JSF 2.0 и JSF 2 –> Portlet 2 Bridge (http://www.portletfaces.org) и IceFaces (http://www.icefaces.org). Ще бъдат разгледани също допълнителни примери за JavaScript портлети и използване на новата JS библиотека Alloy UI базирана върху YUI3 (http://yuilibrary.com/projects/yui3), която замени jQuery при Liferay 6.

За лекторите

Траян Илиев е магистър по Информатика от Софийски университет „Св. Климент Охридски“. От 2003 той е управител на IPT – Intellectual Products & Technologies (http://www.iproduct.org). Компанията е специализирана в провеждането на обучения по JAVA^™ SE/EE технологии.

От 2000 година той преподава в Софийски университет, Факултет по математика и информатика, където води курсове: Обектно ориентиран анализ и проектиране с езика UML, Информационни и комуникационни технологии, Системи за подпомагане вземането на решения, Мултимедийни технологии, Изкуствен интелект. Участвал е в редица национални и европейски изследователски проекти.

Сред неговите технически и изследователски интереси са Service Oriented Architecture, business systems and process modeling using UML and BPMN, Java portlets and portal frameworks (Liferay, GateIn, etc.), AJAX and JavaScript libraries, Java EE technologies (EJB 3.1, JSF 2.0, JPA 2.0, EJB^™ 3.1, JSF 2.0, REST-ful web services, WSRP), Java multithreading, multi-agent technologies (http://www.h2j.org).

Включване на Log4J логинг на Tomcat в Eclipse

Java, Software Design & Development No Responses »

сеп 102011

Без съмнение при разработването на Java-базирани уеб приложения, Eclipse и Tomcat са избор по подразбиране. Обикновено предпочитам да използвам предварително инсталиран Tomcat, използвайки го през Eclipse. В този случай обаче, по подразбиране, логгинга на Tomcat не работи, което обикновено е доста дразнещо, тъй като не ни се иска да се връщаме в тъмните времена на System.out.println() (което добавя още един аргумент към молбата на Мишо за подобряване на интеграцията между Eclipse и Tomcat).

Включване на логването под Tomcat, който се управлява от Eclipse

За включване на логването под Tomcat, който се управлява управлява от Eclipse, са нужни следните стъпки:

Подготвя се конфигурационния log4j.properties файл, намиращ се в директория [LOG4J_PROPS_LOCATION]
В Eclipse се маркира се желания сървър в менюто за подпрозореца за сървърите (вж. снимката по-долу)

Open (F3) > Open launch configuration > Arguments > VM arguments:
Като последен аргумент се добавя следното:

-Djava.util.logging.config.file="[LOG4J_PROPS_LOCATION]/logging.properties" -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager

Местоположение на конфигурационните файлове на Tomcat

Когато конфигурирам Tomcat, предпочитам конфигурационните файлове да бъдат в директорията на сървъра. Когато сървърът се стартира през Eclipse обаче, това не е толкова лесно.

Когато се създаде сървър под Eclipse, използвайки независима Tomcat инсталация, физически конфигурационните файлове на сървъра се съхраняват в следната директория “[ECLIPSE_WORKSPACE]/.metadata/.plugins/org.eclipse.wst.server.core".

В тази папка, в отделни поддиректории се пазят конфигурационните файлове на всеки един от сървърите “създадени” през Eclipse. Поддиректориите са именувани с tmp[i], където с [i] е означен поредния номер на сървъра в зависимост от последователността на създаването му. Например за следните сървъри

имаме съответните конфигурационни директории:

drwxrwxrwx   1 user     group           0 Aug 22 08:54 tmp0
drwxrwxrwx   1 user     group           0 Aug 22 08:55 tmp1
drwxrwxrwx   1 user     group           0 Aug 29 17:23 tmp2

Всяка една от папките има структура подобна на подразбиращата се за Tomcat:

d:eclipse-workspace.metadata.pluginsorg.eclipse.wst.server.coretmp2>ls -al
total 0
drwxrwxrwx   1 user     group           0 Aug 29 17:23 .
drwxrwxrwx   1 user     group           0 Aug 29 17:23 ..
drwxrwxrwx   1 user     group           0 Aug 29 17:23 conf
drwxrwxrwx   1 user     group           0 Aug 29 17:23 logs
drwxrwxrwx   1 user     group           0 Sep  9 19:37 temp
drwxrwxrwx   1 user     group           0 Aug 29 17:23 webapps
drwxrwxrwx   1 user     group           0 Aug 29 17:23 work
drwxrwxrwx   1 user     group           0 Sep  9 13:18 wtpwebapps

Отново, по подобие на конфигурацията на стандартната инсталация на Tomcat, поставяме конфигурационния файл на Log4J log4j.properties в папката conf, изпълняваме стъпките описани в предходната секция и voilà, логването е включено.

Промяна на местоположението на Maven-хранилището на локалния компютър

Java, Software Design & Development No Responses »

авг 202011

Рано или късно, след една, две или няколко преинсталации на операционната система, всеки от нас достига до извода, че трябва да инсталира потребителските програми на дял/твърд диск, различен от системния. Да, но повечето програми, при инсталиране имат предефинирани настройки, които обикновено (поне в случая с Windows) очакват, че инсталацията на сътоветната програма е на системния дял. Подобен е случая и с Eclipse и Maven.

Промяна на Maven хранилището на локалния компютър

Дори Maven да е инсталиран на дял различен от системния, по подразбиране Maven хранилището на локалния компютър се очаква, че ще бъде по подразбиране точно на системния дял:

за Windows (Vista/7) то е в C:\Users\<WINDOWS_USERNAME>\.m2\repository
за Linux в ~/.m2/repository

Ако искаме да променим местоположението на локалното хранилище, да бъде на дял различен от системния например, единственото, което е нужно да направим е да променим конфигурационния файл на Maven – settings.xml, намиращ се в инсталационната директория на Maven. За целта, разкоментираме тагът localRepository и добавяме пътя до новата директория, която ще бъде използвана за хранилище:

<settings>
...
<localrepository>/path/to/local/repo/</localrepository>
...
</settings>

В моя случай, промяната изглежда по следния начин:

<settings>
...
<localrepository>D:/config/maven/.m2/repository</localrepository>
...
</settings>

Eclipse и новото хранилище

По подразбиране Eclipse използва собствена инстанция на Maven. За локално хранилище, по подразбиране, използва следните папки:

за Windows (Vista/7) в C:\Users\<WINDOWS_USERNAME>\.m2\repository
за Linux в ~/.m2/repository

Ако инсталираме Maven на място различно от това по подразбиране и конфигурираме локалното хранилище да бъде на място различно от това, което се очаква по принцип, инсталирането на генерираните от Maven архиви (jar,war, и т.н.) в локалното хранилище, ще се записват на новоуказаното място.

Ако не отразим тези промени и в Eclipse, той ще използва собствената инстанция на Maven и собствени настройки за локално Maven хранилище. Съответно, ако Eclipse не намери папката .m2/repository в директорията на текущия потребител (user.home) на системния дял/диск, той я създава и инсталира генерираните архиви от Maven проектите там. Така, компилирането и инсталирането (в термините на Maven) на едни и същи проекти от командния ред и от Eclipse, ще доведе до съхраняването на архивите съответно на две различни места.

Нещо повече, не винаги версията на Maven, която Eclipse използва (M3 за Eclipse 3.6.1 например), съвпада с тази, която използваме в текущия проект (M2 за проекта, по който работя в момента). Както знаем, поради нововъведенията направени във връзка оптимизирането на работата на Maven във версия M3, Maven проектите, компилирани с тази версия са несъвместими с М2 и обратно.

Така можем да обобщим следните проблеми при промяна на локалното хранилище (и инсталация) на Maven, но неотразяването им в Eclipse:

Отново съхряняваме потребителски файлове на системния диск (тези генерирани от Eclipse);
Нямаме синхронизация при компилирането на проектите през команден ред или през средата за програмиране (компилиране през конзолата не води до промяна в Eclipse);
Възможна несъвместимост на файловете генерирани през команден ред и Eclipse в случай, че са използвани различни версии на Maven.

За да ги избегнем, трябва да направим две промени в настройките на Eclipse. Отваряме менюто Window > Preferences и променяме:

Указваме на Eclipse да използва новата инсталация на Maven: Maven > Installations > Add... и избираме директорията, %MAVEN_HOME%, която сочи към новата инсталация на Maven и която ще бъде използвана през командния ред.
Пренасочваме Eclipse да използва новото хранилище: Maven > User Settings > User Settings > Browse и избираме местоположението от settings.xml конфигурационния файл на Maven, което описва къде се намира в новото локално хранилище (обяснено в предходната секция).

По този начин уеднаквяваме версиите на Maven и на Maven хранилището използвани през командния ред и Eclipse.

BDD with JBehave

Java, Software Design & Development No Responses »

юли 152011

Преди месец, на семинар на Българската Java потребителска група, направих презентация, “BDD с JBehave и Selenium”, с която се опитах да представя концепцията за разработка на софтуер ръководена от поведението на софтуера (Behaviour Driven Development) и основите на JBehave (конкретна BDD технология). Презентацията съдържа още и пример, който онагледява как JBehave може да бъде интегриран със Selenium, във връзка с тестването на уеб интерфейси използвайки BDD.

Презентацията може да бъде намерена на профила ми в Slideshare:

BDD with JBehave and Selenium

View more presentations from shadrik

Кодът от примерите и самата презентация могат да бъдат свалени също и от Google Code хранилището на групата: http://tinyurl.com/6xoz4sp

Кодът и презентацията са публикувани под CC-BY лиценз.

Зареждане на .properties ресурсни файлове в Java

Java 2 Responses »

окт 102007

Във връзка с въпроса:

Къде (и в какъв ред) се търсят *.properties файловете, когато се зареждат с:
ResourceBundle.getBundle(filename)

се поразрових и преведох следната интересна информация:

1) .properties файловете се зареждат от classloader-а, подобно на .java класовете, т.е. трябва местоположението им да е включено в CLASSPATH променливата на средата.

2) .properties файловете имат пълно име (fully-qualified-resource-name), както при .java класовете, с изключение на това, че не може да се извършва import на ресурcи (.properties файлове) в някой .java клас.

ResourceBundle.getBundle("myBundleProps")

указва на classloader-a да зареди ресурс с име myBundleProps в пакета по подразбиране. Това не значи, че ресурса трябва да е в текущия пакет, в който е класа, от който се зарежда.

ResourceBundle.getBundle("package1.package2.package3.myBundleProps")

указва на classloader-a да зареди ресурс myBundleProps с пакет package1.package2.package3. Неговото пълно име (fully-qualified-resource-name) съответно е
package1.package2.package3.myBundleProps.

Т.е. ако директорийната структура на проекта е следната:

project_path
    +-- src
    |      +-- package1
    |            +-- package2
    |                  +-- package3
    |                        +-- TestResourceBundle.java
    +-- classes
           +-- package1
                 +-- package2
                       +-- package3
                             +-- TestResourceBundle.class
                             +-- myBundleProps.properties

и ако в TestResourceBundle.java, ResourceBundel класa се зарежда със следният код:

ResourceBundle myBundleProps = ResourceBundle.getBundle(
                                                   "myBundleProps");

е нужно myBundleProps.properties да се копира в project_path/classes, на същото директорийно ниво на project1 папката. Като алтернатива може да се пакетира myBundleProps.properties в един .jar файл, така че myBundleProps.properties да е в главната директория в .jar архива, който няма никакви поддиректории архивирани в него. След това трябва да се добави този .jar файл в CLASSPATH променливата на средата.

Ако в TestResourceBundle.java се зарежда обект от тип ResourceBundel със следният код:

ResourceBundle myBundleProps = ResourceBundle.getBundle(
                       "package1.package2.package3.myBundleProps");

Тогава е нужно да се копира myBundleProps.properties в
project_path/classes/package1/package2/package3. Като алтернатива, може да се сложи
package1/package2/package3/myBundleProps.properties съответно в един .jar файл (запазвайки директорийната структура на пакетите и в него) и да се добави този .jar файл в CLASSPATH променливата на средата.

Причините за гореописаните начини за употреба на .properties ресурсни файлове са следните:

1) Прозрачност в локализирането на файла – по време на изпълнение на програмата, myBundleProps.properties НЕ е файл, той е просто ресурс, който се зарежда. myBundleProps.properties може да не се съдържа в проекта като цяло, и човека който пише TestResourceBundle.java може изобщо да не види този ресурс. Един URLClassLoader може да го намери в мрежовия път или в URL по време на изпълнение. Това специално е важно за server-side компоненти като EJB, Servlet, JSP и т.н., който по принцип нямат достъп до файловата система. При опит да се получи даден ресурс от classloader, няма значение къде се съхранява съответният ресурс.

2) Mеханизма при работа когато имаш namespaces – конструирайки програмата с пакети, това позволява множество други пакети да съдържат ресурсни файлове (.properties файлове) със същото кратко име (в случая myBundleProps.properties) без това да причинява конфликти в цялата работа на системата. Това е като java пакетите и xml namcesaces.

[Източник: http://blogs.sun.com/chengfang/entry/p_java_util_missingresourceexception_can]