Spring Boot running in 2 min

Spring Boot 1.0.1 is released. I wanted to find the fastest way to get a spring boot app running. The usual “Hello world” was created and running in around 2 minutes. For the creation of the initial project files I used lazybones. The project template uses gradle as build tool. So I had to install gradle too. And the easiest way to install lazybones and gradle is gvm.

Install gvm:

curl -s get.gvmtool.net | bash
source "//.gvm/bin/gvm-init.sh"

Install gradle and lazybones:

gvm install gradle
gvm install lazybones

Create a project with the name “mycrm” with the template “spring-boot-actuator”:

lazybones create spring-boot-actuator mycrm

Change into project directory and build the runable jar:

cd mycrm
gradle bootRepackage

Run the application:

java -jar build/libs/spring-boot-sample-actuator-1.0.0.jar &

Get the hello world 🙂

wget -O - localhost:8080 | less

Done.

 

running all tests of vert.x on a gentoo box

so after setting up the dev environment (btw. IDEA setup was much smoother) I wants to run all tests via

$./mk test

After getting errors like:

Exception in Ruby verticle: no such file to load -- rubygems

or

Exception in Ruby verticle: no such file to load -- json

I figured out that I have to install ruby and jruby properly on my Gentoo box. In short, run the following commands:

$sudo emerge -va dev-java/jruby dev-ruby/rubygems dev-lang/ruby
$sudo eselect ruby set ruby19
$sudo jruby -S gem install json

and add the following lines to your ~/.bashrc

...
export JRUBY_HOME=/usr/share/jruby
export RUBY_HOME=/usr/lib64/ruby/1.9.1
...

Don’t forget

$source ~/.bashrc

I used

$equery files jruby

and

$equery files ruby

to find the right directories.

Result:

$~/mk test

...

Information: Starting test: test_echo_binary

:test

BUILD SUCCESSFUL

Total time: 2 mins 19.355 secs

vert.x, the new gradle build and Eclipse 4.2

Developing vert.x with Eclipse 4.2:

  1. Fork the vert.x repo at github (help) and clone it to your local machine (let’s say to /tmp/vert.x )
  2. change directory cd /tmp/vert.x und run ./mk eclipse
  3. Install Gradle 1.0 / Java SDK 7 / Eclipse 4.2 (Eclipse Classic)
  4. Optional Install Grovvy Eclipse Plugin
  5. Start Eclipse and import  every project (I can’t find a solution to import all at once.)
    1. Import…
    2. Existing Projects into Workspace
    3. Select root directory
      1. /tmp/vert.x
    4. Finish
    5. Import…
    6. Existing Projects into Workspace
      1. /tmp/vert.x/vertx-boot
    7. Finish
  6. Seclect Project vert.x
    1. Right click
    2. Team -> Share Project
    3. Git
    4. Next, Finish
  7. Project -> Clean -> Clean all Projects
  8. Happy Hacking

I read about gradle support in SpringSource STS but I did not tried it.

java.io.NotSerializableException – but where is the field?

To enable more informations about “java.io.NotSerializableException” just add the “-Dsun.io.serialization.extendedDebugInfo=true” VM argument to your run configuration.

Example: java -Dsun.io.serialization.extendedDebugInfo=true -jar your.jar

Without extendedDebugInfo:

Exception in thread "main" java.io.NotSerializableException: net.nautsch.addressbook.Country
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1164)
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330)
at net.nautsch.addressbook.App.main(App.java:33)

and with:

Exception in thread "main" java.io.NotSerializableException: net.nautsch.addressbook.Country
- field (class "net.nautsch.addressbook.Address", name: "country", type: "class net.nautsch.addressbook.Country")
- object (class "net.nautsch.addressbook.Address", net.nautsch.addressbook.Address@13caecd)
- field (class "net.nautsch.addressbook.Person", name: "address", type: "class net.nautsch.addressbook.Address")
- root object (class "net.nautsch.addressbook.Person", net.nautsch.addressbook.Person@158b649)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1161)
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330)
at net.nautsch.addressbook.App.main(App.java:33)

Gesetz von Demeter, Unit Tests und der zweite Programmierer

In meinem letzten Post habe ich beschrieben, das Delegation für den Benutzer einer Klasse angenehm ist und das wir dies auch im realen Leben schätzen. Heute möchte ich kurz beschreiben wie sich das Einhalten des Gesetzes von Demeter auf das Schreiben von Unit-Tests und das Benutzen meiner Implementierungen auswirkt. Dazu habe ich das Modell um Implementierungen erweitert:

lod overview 1

Continue reading “Gesetz von Demeter, Unit Tests und der zweite Programmierer”

Gesetz von Demeter im Alltag

In den letzten zwei Monaten hatte ich im Umfeld der Software-Entwicklung sehr viel dieser “AHA”-Effekte. Da das Gehirn neue Erkenntnisse mit dem Ausschütten von Glückshormonen belohnt, war es eine sehr gute Zeit für mich. 🙂

Als heute  morgen alle noch bei Kaffee in unserem Pausenraum sassen, habe ich ein speziellen Teil unseres Domain Modells an die dort hängende Tafel gemalt. Ich wollte allen mitteilen, auf welch schönes Design wir gestern für einen Teil unseres Domain Modells gekommen waren. Insbesondere wollte ich auch aufzeigen, wie elegant eine Lösung werden kann, wenn man sich an das Gesetzt von Demeter hält. Dabei haben Jan und ich nicht mal an das Gesetz gedacht, als wir die Schnittstellen definiert haben. Es ist sozusagen “einfach entstanden”.

Hier ein leicht abgeändertes Beispiel:

lod 1

Continue reading “Gesetz von Demeter im Alltag”

Spring Greenpages mit Teneo

Beim SpringSource® dm Server™ ist ein Beispiel dabei, welches Greenpages heisst. Vor ein paar Wochen durfte ich auf Arbeit mal ausprobieren, ob Teneo mit dem dm-Server läuft. Also habe ich mir das Beispiel von SpringSource geschnappt und die Sache angeschaut.

Es hat funktioniert!

Leider habe ich erst heute Zeit gefunden, den Source auf bitbucket zu stellen. Es hat noch hässliche Sachen drin.  Mir ist es in der Klasse TeneoDirectory zum Beispiel nicht gelungen, die Transaktionen deklartiv einzubauen. Ich hole jetzt von der EntityManagerFactory einen EntityManager und von dort die Transaktion. Anders habe ich es einfach nicht hinbekommen… und irgendwann war die Zeit zu Ende.

Wenn jemand eine andere Lösung hat, bitte unbedingt melden.

Netbeans, Ivy und Spring 3.0.0M4

Ich programmiere gerade eine kleine Web-Applikation und möchte dazu die neuen REST-Features vom Spring-Framework benutzen. Bis gestern habe ich mir dazu in Netbeans ein Webprojekt gebaut und dann ganz artig alle notwendigen Bibos von Hand dem Projekt hinzugefügt. Gestern wurde nun der Milestone 4 von Spring 3.0.0 veröffentlicht und ich wollte mir nicht noch einmal die Arbeit machen.
Continue reading “Netbeans, Ivy und Spring 3.0.0M4”