Total Pageviews

Thursday, April 19, 2012

Logging in Java: Switching to logback and slf4j

log4j was and maybe still is the de facto standard when it comes to logging in Java applications.
Sun's solution with the internal JDK logging could not be enforced across the board. The reasons for this are certainly the lack of configurability and flexibility. For simple projects the JDK logging is certainly a solution, but not for enterprise applications.

Now, in addition to log4j a new implementation that is more powerful, faster and more flexible than log4j has entered the market: logback. Ok, in fact logback was started in 2006, but version 1.0 was released in Nov. 2011.

logback has been created as a successor to log4j by the same developer and is now available after many years of testing and development in a version 1.0 (current version is 1.0.1). To avoid misunderstandings due to the small version number it should be said that logback is already in use for years in business and the version number does not reflect in any case a statement about the stability or functionality.

logback provides several advantages over log4j. Among other things:
  •      Much faster implementation
  •      Automatic reloading of logging configuration
  •      Better filter
  •      Automatic compression of archived log files
  •      Stack traces with information about the manufacturing Java Package (jar file)
  •      Automatic removal of old log archives

For the developer a switch from log4j to logback is very easy. Just switch a dependency in your Maven POM and you are ready to go:

 <dependency>  
   <groupId>ch.qos.logback</groupId>  
   <artifactId>logback-classic</artifactId>  
   <version>1.0.0</version>  
 </dependency>  

Thanks to the transitive dependencies you now also have the logging facade slf4j added to your project.
A "Hello World" example using slf4j looks like this:

 package demo;  
 import org.slf4j.Logger;  
 import org.slf4j.LoggerFactory;  
 public class HelloWorld {  
   public static void main(String[] args) {  
    Logger log = LoggerFactory.getLogger(HelloWorld.class);  
    log.info("Hello World");  
   }  
 }  

All that remains is a configuration file to control log output. 

With log4j it is usually called log4j.xml. With logback it is called logback.xml or logback-test.xml for testing environment.

In Maven projects the file logback.xml must be placed into $PROJECT_HOME/src/main/resources. The file logback-test.xml must be placed into $PROJECT_HOME/src/test/resources. A simple configuration looks like this:

 <configuration>  
  <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">  
   <!-- encoders are assigned the type  
      ch.qos.logback.classic.encoder.PatternLayoutEncoder by default -->  
   <encoder>  
    <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>  
   </encoder>  
  </appender>  
  <root level="debug">  
   <appender-ref ref="STDOUT" />  
  </root>  
 </configuration>  

The complete manual for logback is very detailed and available here.

Wednesday, April 18, 2012

Moving default progress indicator and make it modal in Vaadin

The default progress indicator in Vaadin is displayed at the upper right corner of your web application. Sometimes this is not the best location, especially if you want your users not to miss this little image. So just place the progress indicator into the centre of the screen.
The progress indicator is by default not modal, so users can still interact with the web application. Maybe this is not what you want and you would like to make the progress indicator modal so users can't interact with the web application during a long running process.
To summarize the goals:
  1. Move default progress indicator from upper right corner to centre
  2. Make indicator modal, so users can't interact during a long running process
The easiest thing to accomplish this is to edit the styles.css file of your Vaadin theme. If you use the standard theme you may want to extend it by creating your own styles.css for your theme.
I use the reindeermods theme so the styles.css example provided below extends exactly that theme.
The minimal styles.css solution to solve the requirements:

 
 @CHARSET "ISO-8859-1";
 @import url(../reindeermods/styles.css);

 .v-loading-indicator,  
 .v-loading-indicator-delay,  
 .v-loading-indicator-wait {  
   width: 100%;  
   height: 100%;  
   margin: 0;  
   background-position: 50%;  
   background-color: gray;  
   background-repeat: no-repeat;  
   background-attachment: fixed;   
   opacity: .8;  
   -ms-filter: alpha(opacity=80);  
   filter: alpha(opacity=80);  
 }  

This solution was taken from this Vaadin forum post.

Friday, April 13, 2012

How to edit UTF-8 resource properties in Eclipse

Editing resource properties files in Eclipse is easy - as long as you don't need characters beyond the ISO-8859-1 encoding.
Characters that cannot be directly represented in this encoding can be written using Unicode escapes.
I really don't know all Unicode escapes for german umlauts and I don't want to waste my time with those things when editing properties files.

The first solution I tried was to create my properties file with an UTF-8 encoding using Notepad++. This works pretty well as far as you don't touch this file ever again with Eclipse :-(
Any change of the file using Eclipse converts this file back to ISO-8859-1 encoding and native umlauts like "ä" and "ü" will display strangely in your application.

Note: In Eclipse Preferences every encoding setting (Workspace, CSS, HTML, JSP, XML) was set to UTF-8. In this Stackoverflow question someone tried even the option of specifying -Dfile.encoding=UTF-8 in eclipse.ini. Still not working.

BTW, if you prefer creating and maintaining UTF-8 properties files (maybe you don't work with Eclipse or use another IDE/Editor which is capable of editing UTF-8 property files) you have to check out this stackoverflow posting. Both code examples of reading resource bundles in UTF-8 format work like a charm.

For me, this is not an option because I want to stick to Eclipse and I don't want to edit the properties files with a different tool.

What finally really did the trick was the Resource Bundle Plugin for Eclipse mentioned in this stackoverflow answer. The plugin converts native non ISO-8859-1 characters on the fly to Unicode escapes and frees you from typing the Unicode escapes manually.
All in all a pretty good solution and a very handy plugin.




Thursday, April 12, 2012

Adding Vaadin Add-Ons to your Maven managed application

One of the things I really like about Vaadin is the simplicity and the speed when developing the UI with Vaadin. Another great benefit of Vaadin is its Add-On directory where lots of useful add-ons are maintained and provided.

Add-Ons which implement client side UI must be recompiled by the GWT compiler to include them into your app.
To me it was not clear how to do that precisely despite the docs provided here and here.

I found this great blog article describing the necessary steps to use Add-ons with Maven. This is especially useful and described in detail for using Add-Ons which implement client side (JavaScript) code.

To minimize compile time I recommend to use a maven profile as described in the article. This prevents a GWT compilation of the widgetset each time the project is built.

In my case I used version 2.3.0 for GWT and for the gwt-maven-plugin.

Sunday, April 08, 2012

Using Eclipse 3.7 and GlassFish 3.1.2 server runtime plugin under Windows to control GlassFish servers

I installed GlassFish 3.1.2 Open Source Edition on my Windows 7 box and wanted to manage the GlassFish instance from Eclipse 3.7 using the GlassFish server runtime plugin.
I installed the plugin via the eclipse marketplace and found out that the version from the marketplace doesn't support GlassFish 3.1.2.
So I googled around and found out about this blog post describing how to install the GlassFish server runtime plugin properly on Eclipse 3.7. There is also a great stackoverflow question describing the problems with multiple "internal GlassFish servers" each time you start Eclipse after you have installed the server runtime plugin for GlassFish 3.1.2.
The later problem only occurs on Windows machines!

Tuesday, March 20, 2012

Voodoo Lab Pedal Power 2+ in Pedaltrain PT Pro einbauen - Auf die richtige Bohrlochgröße kommt es an

So, es ist vollbracht :-)
Ich habe meine zwei Voodoo Lab Pedal Power 2+ Netzteile unterhalb meines Pedaltrain PT Pro Boards angebracht.
Durch meinen Bodentreter-Wahn reichte ein Pedal Power Netzteil leider nicht mehr aus. Aber das schöne ist ja, dass das Pedaltrain Board großzügigen Platz bietet und man locker zwei oder sogar drei Voodoo Labs darunter schrauben kann.
Ich hatte allerdings mit ein paar Schwierigkeiten zu kämpfen.
  1. Das Pedaltrain PT Pro Board besitzt nur einen Satz an Befestigungshalterungen und Schrauben für eben genau ein Voodoo Lab. Diese Befestigungshalterungen mal eben so zu besorgen ist nicht ganz einfach. Selbst mein "Local Dealer" um die Ecke hat mehrere Wochen gebraucht. Da ich solange nicht warten wollte hab ich mir dann welche bei einem ebay Händler aus den USA gekauft die preislich mit Versandkosten genauso teuer waren wie beim Kauf in einem Geschäft vor Ort. Die Lieferzeit betrug knapp 2 Wochen und war damit sogar noch etwas schneller als in meinem Gitarrenladen. Im Endeffekt scheint es aber ziemlich egal zu sein, ob man die Halterungen vor Ort in dem Laden seiner Wahl bestellt (vorrätig sind die meiner Erfahrung nach so gut wie nie) oder aus den USA importiert.
  2. Das Befestigen der Halterungen ist prinzipiell ein Klacks. Es gibt im Internet massenweise Anleitungen dafür. Zum Beispiel diese hier mit einer guten Bebilderung (nicht für ein PT Pro, aber das Prinzip ist das gleiche) oder diese hier als Video bei youtube.
    Das einzige Problem das ich hatte war, dass alle Anleitungen auf englisch sind. Nicht, dass ich des englischen nicht mächtig wäre - ganz im Gegenteil - aber die Maßeinheiten und die Umrechungen vom englischen ins metrische System waren eine kleine Herausforderung. Warum das?
    In allen Anleitungen war die Rede davon, dass man die Löcher mit einem 1/8 drill bit Metallbohrer in das Pedaltrain bohren muss. Also ganz einfach dachte ich mir: Umrechnungstabelle von inch nach Millimetern im Netz suchen und einfach die passenden Bohrer besorgen. Ich hab dann diese Umrechnungstabelle gefunden und war etwas überrascht: Da stehen tatsächlich 2(!) metrische Bohrergrößen für den Wert 1/8 inch drin.
    3.1750 und 3.5000. Äh ja und nu?
    Tja, ich bin dann in den Baumarkt und hab nachgeschaut bzw. auch nochmal Google konsultiert: Es gibt entweder 3mm oder 3,5mm Bohrer. Ok, hab ich dann einen Set gekauft, der beide Bohrergrößen enthält. War auch nicht teuer und kann man sicherlich immer mal wieder gebrauchen.
  3. Jetzt zum bohren: Welche Bohrergröße nimmt man denn dann? Erfahrung meinerseits: Nimm den 3,5mm Bohrer. Ich habe zuerst den 3mm Bohrer benutzt und da ist mir beim Eindrehen einer Schraube der Schraubenkopf tatsächlich abgebrochen. Das gebohrte Loch war zu schmal. Und nein - ich habe die Schraube nicht mit einem Akkubohrer eingeschraubt sondern ganz old-school per Hand.
    Mit den 3,5mm Löchern hat dann aber alles perfekt geklappt.

Ein Foto des fertigen Boards wird es sicherlich auch nochmal geben. Aber es sind noch nicht alle Effekte drauf und das Kabelwirrwarr muss erst noch "schön gemacht" werden.

Übrigens hab ich jetzt ein Rockcase 80x40 Board über. Sehr guter Zustand und wenig benutzt ...

Solution for "Sniffers with type [connector] and type [ejb] should not claim the archive at the same time"

In case you are using GlassFish it may happen you run into this error

"java.lang.IllegalArgumentException: Sniffers with type [connector] and type [ejb] should not claim the archive at the same time. Please check the packaging of your archive" 

In my case it happens when I deployed a web archive out of Eclipse directly into a running GlassFish instance on my machine using the GlassFish plugin. 
I tried a Google search for this error and found a blog posting by Adam Bien describing this error and a solution. Well, indeed my packaging was wrong. I accidentally bundled the artifact glassfish-embedded-all into my WAR archive and this was causing the trouble.
The solution is very simple: Either change the scope in your pom.xml to "provided" or - in case you don't need the dependency - remove it from the dependency section of your pom.
In my case it turns out that the dependency was not necessary anymore and I deleted it.

Monday, March 05, 2012

Stopping Tomcat with remote JMX enabled through script

Tomcat comes with handy start and stop scripts in the bin folder. Those scripts are working very well.
With this script it's pretty simple to start/stop Tomcat on linux systems.

But if you decide to add jmxremote properties to your start script using $JAVA_OPTS variable, stopping of Tomcat (and mostly any other AppServer started with these options) will not succeed.

There will be an error message stating that the address is already in use (BindException) and you have to kill the process manually.

The solution is very simple. Make sure the stop command does not contain the jmxremote properties definition. So you might declare a $JAVA_OPTS for the start command as usual:

 JAVA_OPTS="-Xmx256m -XX:MaxPermSize=128m 
-Dcom.sun.management.jmxremote.port=3336 
-Dcom.sun.management.jmxremote.ssl=false 
-Dcom.sun.management.jmxremote.authenticate=false 
-Djava.rmi.server.hostname=192.168.1.5"  


but for the stop command you must omit those jmx definitions and declare it for example like this:

 JAVA_OPTS_STOP="-Xmx256m -XX:MaxPermSize=128m"  
.
The stop command then forks a JVM with the $JAVA_OPTS_STOP definition NOT trying to open another listening socket on an already bound port.


Thursday, March 01, 2012

Setting up an Apache cluster under RedHat Enterprise Linux

If it ever happens that you have to set up an Apache Linux cluster, I highly recommend the step-by-step manual from clusterlabs.org.
The docs are really easy to read and are very helpful.
I only have two negative points:

  1. Sometimes the commands you have to enter into the console are not clearly separated from the parameters or text you have to pass. Example:
    cat <<-END >>/etc/corosync/service.d/pcmkservice {
            # Load the Pacemaker Cluster Resource Manager
            name: pacemaker
            ver:  1
    }
    END
    The file to create is called /etc/corosync/service.d/pcmk (NOT pcmkservice) and the content of the file starts with "service {
    # Load the Pacemaker ..."
    I assume this has something to do with the formatting of the docs.
  2. The docs almost never tell you what to do in case things go wrong or you did a typo or your environment differs from the one used in the docs.
    In that case you have to use google and cross your fingers or use other resources like this one.
After all I only had to consult google once during the complete setup.
My failover tests succeeded after a few hours of setup including writing a howto for my specific setup.
Now the cluster works using corosync and pacemaker as services.

Wednesday, February 15, 2012

Howto dynamically change webservice endpoint URL with Metro

A really cool feature of Metro (and maybe other webservice stacks) is the possibility to change the webservice endpoint URL at runtime.
In general, you typically generate the code via JAX-WS maven plugin (or ant task), specifying the endpoint URL in the generation properties. This is a fast and reliable way to generate webservices. The downside is, that it seems you can't change the endpoint URL at runtime ...
Well, you can. And it is pretty simple.
The example in this posting is taken from the Metro FAQ.

You can use BindingProvider.ENDPOINT_ADDRESS_PROPERTY to set the endpoint address in your client application code.

Sample:

 //Create service and proxy from the generated Service class.   
  HelloService service = new HelloService();   
  HelloPort proxy = service.getHelloPort();   
  ((BindingProvider)proxy).getRequestContext().  
       put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, "http://new/endpointaddress");   
     
  proxy.sayHello("Hello World!");   

With the property key

BindingProvider.ENDPOINT_ADDRESS_PROPERTY
you can also get the currently used endpoint url at runtime. This may be helpful for debugging purposes.
Sample:

 LOG.info("Using endpoint URL: "  
        + ((BindingProvider)proxy).getRequestContext().get(  
            BindingProvider.ENDPOINT_ADDRESS_PROPERTY));