Java – Nikolay´s Technical Blog

REST with Spring HATEOAS

nvasilev — Thu, 13 Nov 2014 02:15:31 +0000

Some days ago there was a seminar held by the Bulgarian Java User Group with topic “REST, HATEOAS, Novelties in JAX-RS 2.0 & Spring HATEOAS”. I talked about the Spring HATEOAS related piece presenting a small demo project I developed beforehand with Spring HATEOAS.

The code along with a few wiki pages with rough explanations of what is done and how to be used are available on my GitHub account.

Call for Authors/Editors

nvasilev — Wed, 21 Aug 2013 08:01:38 +0000

Книга “Класически шаблони за дизайн”

Стартираме нова итерация за писане на книгата с отворен код за “Класически шаблони за дизайн” http://code.google.com/p/design-patterns-book/.

Търсим автори и редактори, които да се включат в проекта.

Свободните теми за писане са следните:

Глава 6. Абстрактна фабрика (Abstract Factory)
Глава 9. Прототип (Prototype)
Глава 10. Сингълтон (Singleton)
Глава 13. Композиция (Composite)
Глава 16. Миниобект (Flyweight)
Глава 18. Верига от отговорности (Chain of Responsibility)
Глава 21. Итератор (Iterator)
Глава 22. Посредник (Mediator)
Глава 25. Състояние (State)
Глава 29. Многослойна архитектура (Multilayer Architecture)
Глава 30. Модел-Представяне-Контролер (MVC)

Наличните теми за редакция са:

Глава 15. Фасада (Facade)
Глава 23. Мементо (Memento)

Ако имате желание да се включите в екипа, ни пишете на design.patterns.book.team [at] gmail.com

Ще Ви бъдем благодарни, ако разпространите това съобщение сред приятели, познати и колеги, които биха били заинтересовани.

Семинар “Eclipse plug-in development”

nvasilev — Thu, 21 Mar 2013 08:56:12 +0000

Днес, 21.03.2013 г, ще се проведе семинар на тема “Eclipse plug-in development” пред българската Java потребителска група (BG-JUG). Семинарът ще бъде в зала 299 на ФМИ с начало19:00 ч.

Повече за семинара

На семинара ще бъдат разгледани следните въпроси:

Кратка история и развитие на платформата Eclipse
OSGi и реализация в Eclipse
Архитектура и основни компоненти на платформата Eclipse
Структура на Eclipse
Разработване на плъгини за Eclipse

По време на семинара ще се наблегне и на новостите в e4.

Лектори

Лектори на семинара ще бъдат Мартин Тошев и Дмитрий Александров.

Това е обявата на събитието и на сайта на BG-JUG.

Втора сбирка на екипа на книгата “Класически шаблони за дизайн”

nvasilev — Thu, 15 Mar 2012 07:00:55 +0000

За сбирката

Книга “Класически шаблони за дизайн”

След първата организационна сбирка (която се състоя на 19.12.20011) и края на първата итерация от проекта за написването на книга за класически шаблони за (софтуерен) дизайн, екипът на книгата реши да се събере отново и втората сбирка ще се състои на 17.03.2012 (събота) от 10 ч, в учебен център “SoftAcad”, намиращ се на следния адрес:

ул. Проф. Кирил Попов 27, кв. Студентски град, гр. София [карта]

За хората, които не са в България и не могат да присъстват физически, ще могат да “присъстват” чрез WebEx конферентен разговор. За целта просто трябва да ни уведомят.

Някои от по-важните теми на сбирката ще са следните:

Състояние на проекта
Ретроспекция на работата до момента (какво мина добре, какво не чак толкова, какво е добре да започнем да правим и т.н.)
Обсъждане на критериите за изключване на несериозни/немотивириани автори от екипа
Организация и продължителност на бъдещите итерации
Избиране на автори и редактори на оставащите теми от книгата

За проекта

Целта на проекта е да се създаде оригинална българска книга с отворен код, по подобие на книгите “Въведение в програмирането с Java” и “Въведение в програмирането със С#”, която предоставя изчерпателна и актуална информация за шаблоните за софтуерен дизайн (design patterns), служейки еднакво добре, както за въведение в материята, така и като справочник. Като евентуално начало на поредица от книги за шаблони за софтуерен дизайн, тази книга ще обхваща най-често използваните (“класически”) шаблони за софтуерен дизайн (GoF patterns). Ако всичко приключи добре, инициативата може да продължи с други поредица от проекти за написване на книги за архитектурни шаблони, интеграционни шаблони, шаблони за конкурентно програмиране и т.н. Друга цел на проекта е да предостави безплатен достъп до електронната версия на книгата. Цената на хартиеното копие ще бъде в размера на разходите за отпечатване и дистрибуция, като сумата събрана от продажбата ще се преизползва за следващи тиражи

Авторският колектив на този проект се ръководи от Цветан Василев, Николай Томитов и мен.

Относно присъединяването на НОВИ автори и редактори

Тъй като се опитваме да ръководим проекта, следвайки модифициран вариант на Scrum методологията, това ни дава възможност да сме гъвкави, относно присъединяването на нови автори и редактори към екипа. В този ред на мисли, ако някой има желание да се включи в проекта, ще бъде добре дошъл(а), стига да е сериозен/сериозна и да има желание да отдели част от свободното си време за създаването на тази книга За целта, моля присъединете се към дискусионната група на книгата и чрез нея се свържете с нас. Връзката с организационния екип на проекта можете да осъществите също, като ни пишете на design.patterns.book.team [кльомба] gmail.com. Естествено, ако имате желание да се включите, можете да дойдете директно на сбирката и да обсъдим включването Ви

Съдържание на книгата за шаблони за дизайн

Книга за софтуерни шаблони за дизайн се състои от няколко части. Първата част представлява кратко въведение в основните принципи на софтуерен дизайн. Втората излага трите групи “класически” шаблони, а именно за създаване на обекти, структурни и поведенчески. Третата част е своеобразен преход към евентуална книга за архитектурни шаблони и представя многослойната архитектура и шаблона MVC. Четвъртата част евентуално ще съдържа материал, който е важен за изложението но не се вписва в контекста на нито една от предходните три части. Книгата ще следва до някъде класическите концепции от GoF, но няма да е превод на тяхната книга, а ще дава съвременно виждане за шаблоните с имплементация на Java и примери от практическия опит на авторите. Следва планираното съдържание на книгата по глави:

Предговор

Част 1. Софтуерен дизайн – общи положения

Глава 1. Основни етапи при разработката на софтуер Глава 2. Принципи и техники на ООП Глава 3.1. Принципи на обектно-ориентиран дизайн Глава 3.2. Принципи SOLID Глава 4. Кратко въведение в UML

Част 2. Класически шаблони за дизайн

Глава 5. Шаблони за дизайн – въведение

Шаблони за създаване на обекти (Creational Patterns)

Глава 6. Абстрактна фабрика (Abstract Factory) Глава 7. Строител (Builder) Глава 8. Метод фабрика (Factory Method) Глава 9. Прототип (Prototype) Глава 10. Сингълтон (Singleton)

Структурни шаблони (Structural Patterns)

Глава 11. Адаптер (Adapter) Глава 12. Мост (Bridge) Глава 13. Композиция (Composite) Глава 14. Декоратор / обвивка (Decorator / Wrapper) Глава 15. Фасада (Façade) Глава 16. Миниобект (Flyweight) Глава 17. Прокси (Proxy)

Поведенчески шаблони (Behavioral Patterns)

Глава 18. Верига от отговорности (Chain of Responsibility) Глава 19. Команда (Command) Глава 20. Интерпретатор (Interpreter) Глава 21. Итератор (Iterator) Глава 22. Посредник (Mediator) Глава 23. Спомен/Мементо (Memento) Глава 24. Наблюдател (Observer) Глава 25. Състояние (State) Глава 26. Стратегия (Strategy) Глава 27. Шаблонен метод (Template Method) Глава 28. Посетител (Visitor)

Част 3. Допълнителни шаблони за дизайн

Глава 29. Многослойна архитектура (Multilayer Architecture) Глава 30. Модел-презентация-контролер (MVC)

Част 4. Приложения*

* в процес на изясняване

Сайт на проекта – безплатна книга за шаблони за софтуерен дизайн

Официалният сайт на книгата за шаблони за софтуерен дизайн за момента е в Google Code: http://code.google.com/p/design-patterns-book. Дискусионна група на проекта е: http://groups.google.com/group/design-patterns-book. Всички активи по проекта са публично достъпни от неговото SVN хранилище: http://design-patterns-book.googlecode.com/svn/trunk/. Следващата итерация (за редакция на написаното до момента) ще започне най-вероятно идната седмица, а тази, за писане на глави, най-вероятно – след две седмици, така че не е късно да се включите. Забележка: Фонът на картинката е от творба на Ешер, взета от този сайт: http://www.wikipaintings.org/en/m-c-escher/symmetry-watercolor-55-fish

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

nvasilev — Mon, 26 Sep 2011 07:27:22 +0000

Българската 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

nvasilev — Fri, 09 Sep 2011 22:42:45 +0000

Без съмнение при разработването на 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-хранилището на локалния компютър

nvasilev — Fri, 19 Aug 2011 21:37:31 +0000

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

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

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

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

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


...
/path/to/local/repo/
...

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


...
D:/config/maven/.m2/repository
...

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

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

за Windows (Vista/7) в C:\Users\\.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

nvasilev — Thu, 14 Jul 2011 21:59:17 +0000

Преди месец, на семинар на Българската 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

nvasilev — Wed, 10 Oct 2007 08:22:09 +0000

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

Къде (и в какъв ред) се търсят *.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]