iFool

Ich habe einen Jetty-Server auf unserem Home-Server (MAC MINI) installiert, um darauf ein paar GRAILS-Anwendungen für den Hausgebrauch zu hosten (Kassenbuch, Dokumenten-Archiv etc.). Fraglich ist nun, wie man einen Daemon so einrichten kann, dass der Jetty-Server bei jedem Start des MAC MINI automatisch (und ohne dass sich ein Benutzer dazu anmelden muss) startet.

Zunächst einmal habe ich ein Start-Script (Filename “Users/Shared/jetty/taustart.sh”) geschrieben, dass ich verwende, um den Jetty-Server einfach mit vorher festgelegten Eingenschaften starten zu können:

cd /Users/Shared/jetty
java -Dtau.config.path=/Users/Shared/jetty/tau-config -DSTOP.PORT=8085 -DSTOP.KEY=stopme -jar start.jar

Wie zu erkennen ist befindet sich das Jetty-Home-Verzeichnis in meinem Fall unter “/Users/Shared/jetty”. Außerdem habe ich dem Server mitgeteilt, dass ich ihn bei Bedarf über den STOP.PORT “8085″ mit den STOP,KEY “stopme” stoppen möchte. Das ist nützlich, wenn ich den Server für Wartungsarbeiten beenden muss. Ab jetzt soll er ja schließlich beim Systemstart automatisch gestartet werden.

Der Clou an der Sache besteht nun darin, dem launch-Daemon (”launchd”) mitzuteilen, dass dieses Start-Script beim booten automatisch ausgeführt werden soll. Dazu erstelle ich eine sogenannte “plist” (Filename “/Library/LaunchDaemons/org.aulich.jetty.plist”) wie folgt:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>Label</key>
    <string>org.aulich.jetty</string>
    <key>ProgramArguments</key>
      <array>
        <string>/Users/shared/jetty/taustart.sh</string>
      </array>
    <key>Disabled</key>
    <false/>
    <key>RunAtLoad</key>
    <true/>
    <key>KeepAlive</key>
    <true/>
  </dict>
</plist>

Jetzt kommt noch ein wichtiger Schritt, den ich zunächst vergessen hatte und mich wunderte, warum meine plist nicht ausgeführt wird: Der Eigentümer der neuen plist sollte “root” sein. Daher verwendete ich das folgende command um den Eigentümer entsprechend auf dem plist-File zu setzen:

sudo chown root /Library/LaunchDaemons/org.aulich.jetty.plist

So, dass ist eigentlich auch schon alles, was geschehen muss, um einen entsprechenden Boot-Daemon einzurichten. Abschließend sei noch angemerkt, dass ich das folgende Script benutze, wenn ich den Jetty-Server zwischendurch mal beenden muss:

cd /Users/Shared/jetty
java -Dtau.config.path=/Users/Shared/jetty/tau-config -DSTOP.PORT=8085 -DSTOP.KEY=stopme -jar start.jar --stop

Allgemein, IT, Software GRAILS, Jetty

Auch bei der Entwicklung einer Anwendung und den damit verbundenen Tests kann es recht lästig sein, immer wieder “zu Fuß” Testdaten eingeben zu müssen. Die von GRAILS automatisch verwendete HSQLDB ist in der Data-Source als inMemory-DB konfiguriert und daher gehen alle erfassten Daten bei jeder Beendigung der Anwendung verloren.

Zwar kann man durch entsprechende Einlassungen im Bootstrap auch Testdaten “beim Hochfahren” generierern, aber das ist für flexible Tests auch nicht so prickelnd, zumal die Erfassung über Programmierung auch Mühen bedeutet.

Eine gute Alternative bietet die Möglichkeit, einfach die HSQLDB-Datasource anzupassen:

 development {
  dataSource {
   dbCreate = "update" // one of 'create', 'create-drop','update'
   url = "jdbc:hsqldb:file:/temp/test/mydb;shutdown=true"
  }
 }

In diesem Beispiel auf einem PC mit Windows 7 wird beim ersten Start ein Verzeichnis C:\temp\test mit folgenden Files erstellt: mydb.lck, mydb.log, mydb.script und mydb.properties.  In den Textdateien mydb.script und mydb.log werden die Tabellendefinitionen und die Daten in lesbarer Form gespeichert. Beim Start der Anwendung wird dann jeweils aus diesen Textdateien wieder eine schnelle “inMemory-DB” aufgebaut. Während die Anwendung läuft werden DB-Änderungen in der *.log-Datei protokolliert, sodass die Daten auch bei einem Crash der Anwendung nicht verloren gehen können.

Die Verwendung von HSQLDB in Verbindung mit Textdeateien zur Speicherung der Daten ist eine bequeme und sofort Verfügbare Alternative für jeden GRAILS-Entwickler. Außerdem kann es auch eine Alternative für den Livebetrieb in Anwendungen mit kleinem Datenbestand sein (bei wenigen Hundert Datensätze etwa).

Allgemein, Groovy & Grails GRAILS

Ich dachte mir, es sei ganz nützlich immer ein Datenbanksystem auf dem Notebook zu haben und installierte mir deshalb schnell mal MySQL. Das war mit dem MSI-Installer für Windows auch garkein Problem: Einfach die Standardversion (derzeit MySQL Server 5.1) ausgewählt und schon war die Basis fix und fertig eingerichtet.

Jetzt galt es nurnoch, eine Datenbank mit gültigem User einzurichten und ein paar Handgriffe im Setup der GRAILS-Anwendung zu unternehmen, die mit MySQL zusammenarbeiten sollte.

Den Job mit der Datenbankeinrichtung hat mir ein kleines Script abgenommen (Dateiname C:\temp\create_rc.sql):

DROP DATABASE RC;
CREATE DATABASE RC;
USE RC;
DROP USER 'rcuser'@'localhost';
CREATE USER 'rcuser'@'localhost';
GRANT ALL PRIVILEGES ON RC.* TO 'rcuser'@'localhost';

Mehr…

Groovy & Grails GRAILS, MySQL

GRAILS macht eigentlich automatisch schon sehr schöne Listen aber “per default” werden dabei leider alle Attribute berücksichtigt. Das führt dann dazu, dass man die unwichtigen ID-Felder zur scheinbar wichtigsten Spalte werden: Sie stehen an erster Stelle und werden dann auch noch mit der “show”-Aktion der zugehörigen Domänenklasse verlinkt.

So wie links im Bild sieht es schon besser aus: Das ID Feld wird unterdrückt und statt dessen das erste (kennzeichnende) Feld gesetzt und verlinkt.

Jetzt könnte man das für jede Domainklasse nach der Generierung der Ansichten (gsp-Views) anpassen, aber das macht keinen richtigen Spaß, denn

1. Wäre das eine relativ stupide Arbeit, die man für jede einzelne Domainklasse durchführen müsste

2. Würde das ganze nach dem nächsten Generieren wiederholt werden müssen

Die Bessere Alternative ist hier die Arbeit mit den Templates, um das GRAILS-Verhalten nachhaltig zu ändern

Mehr…

Groovy & Grails, IT GRAILS

Domainklassen bestimmen hauptsächlich die Eigenschaften der Businessobjekte und die Beziehungen dieser Objekte untereinander. Zu den Eigenschaften gehört die Anzahl, Art und Ausprägung der einzelnen Attribute.

Die Art und Anzahl der Attribute wird durch Deklaration einzelner Objekte und einfacher Datentypen im Kopf der Klasse vorgenommen. Wie kann der Entwickler dann Einfluss auf die gültigkeit der Benutzereingaben nehmen? Hier geht es um Validierung…

In der Abbildung wird ein “Create-Dialog” für eine Domainklasse “Archiv” gezeigt, die 2 Attribute enthält: Name des Archivs und Beschreibung.  Der Benutzer hat mit seinen Eingaben gegen 2 Validierungsregeln verstoßen und ich möchte kurz einmal zeigen, wie soetwas funktioniert.

Mehr…

Allgemein, Groovy & Grails GRAILS

Webanwendungen zu erstellen kann sehr mühsam sein. Ich hatte in der Verganagenheit häufig Probleme mit

• komplexer Softwarearchitektur
• fehlenden Konzepten für eine einheitliche Anwendungsstruktur
• Entscheidungen für das “richtige” Framework
• …

Webanwendungen spielen aber eine immer größere Rolle im LAN bzw. Intranet auch mittelständischer Betriebe. Wenn ich dort als Systemintegrator unterwegs bin um z.B. unser DMS MultiArchive in die Systemlandschaft zu integrieren habe ich schnell die Anforderung auf dem Tisch kleinere Funktionen als Bindeglieder zwischen den Anwendungssystemen neu zu erstellen. Ein Beispiel: Die Wareneingänge zu einem bestimmten Lieferschein sollen direkt aus dem Browser-Frontend von MultiArchive über ein weiteres Browserfenster angezeigt werden können. Das ERP-System bietet diese Funktion aber nicht!

Mehr…

Groovy & Grails GRAILS, Groovy