java – Nikolay´s Technical Blog

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

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

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.

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

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

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\\.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:


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

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


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

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\\.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.

BDD with JBehave

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

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:

BDD with JBehave and Selenium

View more presentations from shadrik

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 ресурсни файлове в 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]