Nov 132014
 

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.

Share
Mar 212013
 

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

eclipse-plugin-development-poster

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

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

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

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

Лектори

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

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

Share
Mar 152012
 

За сбирката

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

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

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

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

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

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

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

За проекта

Целта на проекта е да се създаде оригинална българска книга с отворен код, по подобие на книгите “Въведение в програмирането с 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

Share
Sep 102011
 

With no doubt for the Java web-applications development the Eclipse and Tomcat are default choices. I usually prefer to use preinstalled Tomcat, configuring Eclipse to use the already installed instance. In this case though, by default, Tomcat logging does not work. This in most of the cases is quite anoying, as we don’t want to return in the dark ages of System.out.println() (which adds another argument to Misho’s request for improving the integration between Eclipse and Tomcat).

Enabling the Logging under Tomcat, managed by Eclipse

In order to enable the logging under Tomcat, which is managed by Eclipse, are required the following steps:

  • Prepare the configuration file log4j.properties, storing it in the appropriate directory [LOG4J_PROPS_LOCATION]
  • In Eclipse, select the server in the “Servers Window” (see the picture bellow)
  • Open (F3) > Open launch configuration > Arguments > VM arguments:
  • As last argument should be added the following instructions:
-Djava.util.logging.config.file="[LOG4J_PROPS_LOCATION]/logging.properties" -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager

Tomcat’s Configuration Files Location

When I’m configuring Tomcat, I prefer the configuration files to be located in the server’s directory. When the server is launched by Eclipse though, it’s not that easy.

When a server is “created” under Eclipse, using independent Tomcat installation, the physical location of its configuration files is the following directory “[ECLIPSE_WORKSPACE]/.metadata/.plugins/org.eclipse.wst.server.core". In this directory, under separate subdirectories are kept the configuration files for each of the servers “created” by Eclipse. Subdirectories are named with tmp[i], where [i] is the consecutive number of the server, depending of the order in which the servers are created. For example for the following servers:

there are the following configuration directories:

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

Each of the folders has structure similar to the default Tomcat installation folder:

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

Again, similarly to the standard Tomcat installation, we place the Log4J configuration file log4j.properties in the folder conf, perform the steps from the previous section and voilà, the logging is enabled.

Share
Aug 202011
 

Sooner or later, after a couple of reinstallations of the operating system, each of us reaches the conclusion that the user applications should be installed to a partition/hard-disk, different from the system one. On the other hand, the default configuration of most of the applications by default rely on the fact that the installation of that program is done on the system partition (at least under Windows). That’s the case of Eclipse and Maven as well.

Changing Maven Local Repository Location

Even Maven to be installed on a partition different from the system one, by default the Mavel local repository is expected to be on the system partition:

  • for Windows (Vista/7) it is at  C:\Users\<WINDOWS_USERNAME>\.m2\repository
  • for  Linux – at ~/.m2/repositoy

If we want to change the local repository location, to be on a partition other than the system one for example, the only what is needed is to be changed the Maven configuration file – settings.xml, located in the Maven installation directory. For the purpose, uncomment the tagg localRepository and add the path to the new directory, which will be used for new local repository:

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

In my case, the change looks in the following way:

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

Eclipse and the New Maven Location

By default Eclipse uses its own Maven instance. For local Maven repository, it uses the following folders:

  • for Windows (Vista/7) at  C:\Users\<WINDOWS_USERNAME>\.m2\repository
  • for Linux at ~/.m2/repository

If we install Maven in a location different from the one by default and we configure the local repository to be on a directory different by the one indicated by default, what we could expect is the installation of the generated by Maven archives (jar, war, etc.) in the local repository, to be placed on the newly defined place.

If we don’t reflect these changes in Eclipse, it will use its own Maven installation and its own configuration for the local Maven repository. Respectively, if Eclipse does not find the folder.m2/repository in the current user’s directory (user.home) usually on the system partition/hard-disk, Eclipse creates that folder and install the generated archives for the built Maven projects in it. Thus, the building and installtion (in the terms of Maven) of the same projects from the command line and Eclipse will cause the creation of archives on two different locations.

Moreover, not always the Maven version, which Eclipse uses (M3 in the case of Eclipse 3.6.1 for example) coincide with the one, which is used for the current project (M2 for the project, which I am working on at the moment). As we know, because of the improvements of Maven in version M3 with regards to the optimisation of its performance, the Maven projects, built with this version are incompatible with M2 and vice versa.

So, we can isolate the following problems when we change the local Maven repository and installation, but not reflecting this change in Eclipse:

  • Again we save user generated files on the system partition/disk (the ones generated by Eclipse).
  • We don’t have synchronization when we build and install the Maven projects through the command line and the IDE (the projects built and installed via the command line does not bring changes in Eclipse).
  • It’s possible the archives generated via command line and Eclipse to be incompatible.

In order to avoid all these drawbacks, is required to apply two changes to the Eclipse default configuration. Open the menu Window > Preferences and change:

  • Indicating in Eclipse to use the new Maven installation: Maven > Installations > Add... and chose the directory, %MAVEN_HOME%, which points to the new Maven installation and which will be used through the command line.
  • Configure Eclipse to use the new Maven repository: Maven > User Settings > User Settings > Browse and chose the location indicated in settings.xml configuration file of Maven, which describes where is located to the new local repository (explained in the prvious section).

In that way we unify the Maven versions and local repository used via the command line and Eclipse.

Share
Jul 152011
 

A month ago I gave a talk on Bulgarian Java User Group. The topic was “BDD with JBehave and Selenium”, introducing Behaviour Driven Development concept, JBehave basics and finally presenting an example of how JBehave could be integrated with Selenium.

The slides could be found on my Slideshare account:

The presentation and the code could be downloaded from google code repository: http://tinyurl.com/6xoz4sp

Both of them are published under CC-BY licence.

Share
Oct 102007
 

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

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

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

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

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

3)

ResourceBundle.getBundle("myBundleProps")

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

4)

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]

Share