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.
Днес, 21.03.2013 г, ще се проведе семинар на тема “Eclipse plug-in development” пред българската Java потребителска група (BG-JUG). Семинарът ще бъде в зала 299 на ФМИ с начало19:00 ч.
На семинара ще бъдат разгледани следните въпроси:
По време на семинара ще се наблегне и на новостите в e4.
Лектори на семинара ще бъдат Мартин Тошев и Дмитрий Александров.
Това е обявата на събитието и на сайта на BG-JUG.
Книга “Класически шаблони за дизайн”
След първата организационна сбирка (която се състоя на 19.12.20011) и края на първата итерация от проекта за написването на книга за класически шаблони за (софтуерен) дизайн, екипът на книгата реши да се събере отново и втората сбирка ще се състои на 17.03.2012 (събота) от 10 ч, в учебен център “SoftAcad”, намиращ се на следния адрес:
ул. Проф. Кирил Попов 27, кв. Студентски град, гр. София [карта]
Някои от по-важните теми на сбирката ще са следните:
Целта на проекта е да се създаде оригинална българска книга с отворен код, по подобие на книгите “Въведение в програмирането с Java” и “Въведение в програмирането със С#”, която предоставя изчерпателна и актуална информация за шаблоните за софтуерен дизайн (design patterns), служейки еднакво добре, както за въведение в материята, така и като справочник. Като евентуално начало на поредица от книги за шаблони за софтуерен дизайн, тази книга ще обхваща най-често използваните (“класически”) шаблони за софтуерен дизайн (GoF patterns). Ако всичко приключи добре, инициативата може да продължи с други поредица от проекти за написване на книги за архитектурни шаблони, интеграционни шаблони, шаблони за конкурентно програмиране и т.н. Друга цел на проекта е да предостави безплатен достъп до електронната версия на книгата. Цената на хартиеното копие ще бъде в размера на разходите за отпечатване и дистрибуция, като сумата събрана от продажбата ще се преизползва за следващи тиражи
Тъй като се опитваме да ръководим проекта, следвайки модифициран вариант на Scrum методологията, това ни дава възможност да сме гъвкави, относно присъединяването на нови автори и редактори към екипа. В този ред на мисли, ако някой има желание да се включи в проекта, ще бъде добре дошъл(а), стига да е сериозен/сериозна и да има желание да отдели част от свободното си време за създаването на тази книга 🙂 За целта, моля присъединете се към дискусионната група на книгата и чрез нея се свържете с нас. Връзката с организационния екип на проекта можете да осъществите също, като ни пишете на design.patterns.book.team [кльомба] gmail.com. Естествено, ако имате желание да се включите, можете да дойдете директно на сбирката и да обсъдим включването Ви 🙂
Книга за софтуерни шаблони за дизайн се състои от няколко части. Първата част представлява кратко въведение в основните принципи на софтуерен дизайн. Втората излага трите групи “класически” шаблони, а именно за създаване на обекти, структурни и поведенчески. Третата част е своеобразен преход към евентуална книга за архитектурни шаблони и представя многослойната архитектура и шаблона MVC. Четвъртата част евентуално ще съдържа материал, който е важен за изложението но не се вписва в контекста на нито една от предходните три части. Книгата ще следва до някъде класическите концепции от GoF, но няма да е превод на тяхната книга, а ще дава съвременно виждане за шаблоните с имплементация на Java и примери от практическия опит на авторите. Следва планираното съдържание на книгата по глави:
Глава 1. Основни етапи при разработката на софтуер Глава 2. Принципи и техники на ООП Глава 3.1. Принципи на обектно-ориентиран дизайн Глава 3.2. Принципи SOLID Глава 4. Кратко въведение в UML
Глава 5. Шаблони за дизайн – въведение
Глава 6. Абстрактна фабрика (Abstract Factory) Глава 7. Строител (Builder) Глава 8. Метод фабрика (Factory Method) Глава 9. Прототип (Prototype) Глава 10. Сингълтон (Singleton)
Глава 11. Адаптер (Adapter) Глава 12. Мост (Bridge) Глава 13. Композиция (Composite) Глава 14. Декоратор / обвивка (Decorator / Wrapper) Глава 15. Фасада (Façade) Глава 16. Миниобект (Flyweight) Глава 17. Прокси (Proxy)
Глава 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)
Глава 29. Многослойна архитектура (Multilayer Architecture) Глава 30. Модел-презентация-контролер (MVC)
* в процес на изясняване
Официалният сайт на книгата за шаблони за софтуерен дизайн за момента е в 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
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).
In order to enable the logging under Tomcat, which is managed by Eclipse, are required the following steps:
-Djava.util.logging.config.file="[LOG4J_PROPS_LOCATION]/logging.properties" -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
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.
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.
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:
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>
By default Eclipse uses its own Maven instance. For local Maven repository, it uses the following folders:
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:
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:
In that way we unify the Maven versions and local repository used via the command line and Eclipse.
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.
Във връзка с въпроса:
Къде (и в какъв ред) се търсят *.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]