Alternatives to Spring JMX exporter in JSE/JEE without using Spring framework

Question:
Is there anything similar to the Spring JMX exporter out there WITHOUT using the Spring framework? SimpleJMX (http://256.com/sources/simplejmx/) seems to be reasonable but seems also to be a very young framework pushed only by a single person.

I'm in need of exposing a whole bunch of attributes, methods and classes as JMX but don't want to fiddle with the JMX API and writing tons of JMX interfaces. And there is no way to introduce Spring in the project (just in case you ask). Any hints or ideas are greatly appreciated :-)

Answer:
Ok, I have quickly evaluated SimpleJMX and JMXUtils. Both work as expected and are very similar to the Spring JMX exporter. However, I find JMXUtils to be more usable in my case.

With JMXUtils it is very easy to register/unregister MBeans to an already started platform mbean server. In my case I was using GlassFish V3 as application server and I didn't want to start another MBean Server just for my own mbeans.

As far as I can see the API of SimpleJMX does not allow this and you are either forced to start another MBeanServer using the SimpleJMX API and register the created mbeans (very easy with the API) or you start fiddling around with trying to register the mbeans into the platform mbean server. The later is a little bit more complicated and therefore I decided to use JMXUtils.

The downside of JMXUtils is the manipulation of the bean name. SimpleJMX uses attributes in annotations (domainName, beanName) which is very useful but with JMXUtils you have to know the syntax for naming mbeans when using mbean domains. All in all not a big deal but for my taste SimpleJMX has the better solution for this.

The bottom line is, that both libraries are great and do their job. I decided to use JMXUtils.

This question was also posted in this stackoverflow topic.

Great Android tutorial

If you are planning to develop Android apps check out Lars Vogel's great Android Tutorial. It's one of the best tutorials out there if you are starting Android development from scratch.

Ein hoch interessanter Artikel über außerirdisches Leben in unserer Milchstraße

Wer sich mit der Wahrscheinlichkeit außerirdischen Lebens in unserer Galaxie beschäftigt sollte sich mal diesen Artikel durchlesen.
Bemerkenswerte und wie ich finde sehr interessante Annahmen und Berechnungen.
Unter Umständen muss man die Formeln aber korrigieren, da ja in letzter Zeit immer mehr Exoplaneten entdeckt werden und einige Forscher bereits der Meinung sind, dass es deutlich mehr Planeten gibt, auf denen Leben möglich wäre.
Hierzu gibt es sicherlich aber auch noch eine Menge anderer Meinungen und Berechnungsgrundlagen. Das ganze Thema ist halt sehr stark abhängig vom gegenwärtigen Kenntnisstand und der eingesetzten Technologie und Analyseverfahren.

SSD unter Windows 7 richtig einrichten

Da ich seit kurzem einen neuen Windows 7 Laptop mit einer SSD mein Eigen nennen darf habe ich mir die Tips aus diesem Artikel zu Herzen genommen um die Lebensdauer der SSD zu verlängern.
An und für sich geht Windows 7 schon recht gut mit SSDs um. Seit dem SP1 sogar noch etwas schonender. Dennoch sind einige Einstellungen immer noch nicht akkurat und sollten entsprechend den Tips aus dem Artikel angepasst werden.

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.

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.

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.

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