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.

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!

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.

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.

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.

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));  

Updating GlassFish 3.1 under RHEL 6 on a 64 Bit machine

Don't be surprised when you have problems updating GlassFish 3.1 on a RedHat Enterprise Linux 6 64 Bit machine. This will not work out of the box (officially Oracle only supports GlassFish on RedHat 4 and 5 not on version 6). But there is a way to get it to work.
You will get this error when executing the pkg command:

 [glassfish@MYMACHINE glassfish3]$ pkg list -u  
 Traceback (most recent call last):  
  File "/opt/glassfish/glassfish3/pkg/bin/client.py", line 61, in ?  
   import pkg.actions as actions  
  File "/opt/glassfish/glassfish3/pkg/vendor-packages/pkg/actions/__init__.py", line 59, in ?  
   globals(), locals(), [modname])  
  File "/opt/glassfish/glassfish3/pkg/vendor-packages/pkg/actions/link.py", line 36, in ?  
   import generic  
  File "/opt/glassfish/glassfish3/pkg/vendor-packages/pkg/actions/generic.py", line 45, in ?  
   import pkg.variant as variant  
  File "/opt/glassfish/glassfish3/pkg/vendor-packages/pkg/variant.py", line 28, in ?  
   from pkg.misc import EmptyI  
  File "/opt/glassfish/glassfish3/pkg/vendor-packages/pkg/misc.py", line 49, in ?  
   import zlib  
 ImportError: libz.so.1: cannot open shared object file: No such file or directory  
 ---------------------------------------------------------------  
 There was an error running  
   
 /opt/glassfish/glassfish3/pkg/bin/../python2.4-minimal/bin/python  
   
 You are running on a 64 bit Linux distribution and the 32 bit Linux  
 compatibility libraries do not appear to be installed. In order to use  
 the Update Center tools you must install the 32 bit compatibility libraries.  
   
 On Ubuntu (and possibly other Debian based systems) please install the  
 ia32-libs package. On RedHat 4 (and other RPM based systems), you may  
 need to add multiple 'compat' runtime library packages. Please see the  
 Update Center Release Notes for more information.  
   
   

The solution is to install the following packages using yum

yum install compat-db.i686 zlib.i686 libidn.i686 krb5-libs.i686

The trick is to find out about the correct names of the packages. It's easy on Debian based systems but quiet difficult on RPM based systems.
If you are using CentOS take a closer look at this blog post.

Deep cloning of java objects

I was in need of deep cloning a map with all its keys and values.
All the map implementations in standard Java only do shallow cloning of the map. They don't clone the keys and values. But that was exactly what I want to realize.
I found out about the cloning library which does the job very easy and extremely fast. This library can clone nearly any java object.
A cloning expression is just a two-liner.
Very useful!
On this stackoverflow question you can find more deep cloning libraries.

Don't use commons lang < 2.4 with HtmlUnit

In case you have a project which has a dependency to Apache commons-lang and you plan to use the latest HtmlUnit (as of writing this post this is HtmlUnit 2.9) you should take care of the version of commons-lang.

HtmlUnit is using a method (startsWithIgnoreCase) from commons-lang that was introduced in commons-lang 2.4.
So any commons-lang version below 2.4 will produce runtime exceptions when using HtmlUnit. The stacktrace may be similar to this one:

 java.lang.NoClassDefFoundError: Could not initialize class  
 com.gargoylesoftware.htmlunit.WebClient  
     at net.sourceforge.jwebunit.htmlunit.HtmlUnitTestingEngineImpl.createWebClient(HtmlUnitTestingEngineImpl.java:804)  
     at net.sourceforge.jwebunit.htmlunit.HtmlUnitTestingEngineImpl.initWebClient(HtmlUnitTestingEngineImpl.java:813)  
   
 also :  
   
 java.lang.NoSuchMethodError:  
 org.apache.commons.lang.StringUtils.startsWithIgnoreCase(Ljava/lang/String;Ljava/lang/String;)Z  
     at com.gargoylesoftware.htmlunit.util.URLCreator$URLCreatorStandard.toUrlUnsafeClassic(URLCreator.java:66)  
     at com.gargoylesoftware.htmlunit.util.UrlUtils.toUrlUnsafe(UrlUtils.java:193)  
     at com.gargoylesoftware.htmlunit.util.UrlUtils.toUrlSafe(UrlUtils.java:171)  
     at com.gargoylesoftware.htmlunit.WebClient.<clinit>(WebClient.java:162)  
     at net.sourceforge.jwebunit.htmlunit.HtmlUnitTestingEngineImpl.createWebClient(HtmlUnitTestingEngineImpl.java:804)  
     at net.sourceforge.jwebunit.htmlunit.HtmlUnitTestingEngineImpl.initWebClient(HtmlUnitTestingEngineImpl.java:813)  
   
   
   

In case you use Maven as your build tool you can check the dependencies using the command:

mvn dependency:tree

To avoid this error you can declare version 2.6 of commons-lang in your project.