everflux

Bei Ubuntu wurde der Bereich zum „Anfassen“ der Fensterrahmen auf sagenhafte einen Pixel verkleinert – möchte man ein Fenster nun breiter ziehen muss man schon gut zielen.

Komfortabler geht das derzeit lediglich, wenn man über eine Maus mit drei Tasten verfügt (oder die mittlere Taste simuliert): Hält man die „Alt“ Taste fest, kann man mit der mittleren Maustaste quasi beliebig ins Fenster klicken, und die Größe anpassen. Das ist am Anfang etwas ungewohnt, geht jedoch sogar noch schneller als erst den Fensterrahmen anzusteuern – selbst wenn dieser etwas breiter ist (oder wieder wird).

Es hat nur wenige Monate gedauert, aber dann konnte ich endlich einen besonders nervigen Fehler finden. Ich verwende Maven (wie fast immer) als Buildsystem und habe ein Projekt, dass Eclipse BIRT verwendet.
BIRT nutzt die Eclipse OSGi Plattform und daher werden beim Start einige Bilbiotheken benötigt. Nun gab es das Problem, dass dies im Tomcat nach einer kleinen Anpassung des Classpath prima funktionierte – nicht jedoch wenn ich das Maven Jetty Plugin verwendet habe. Trotz lt. Dokumentation korrekter Konfiguration über webAppConfig und extraClasspath Elemente.

Die Lösung war dann schließlich nicht mehr das maven-jetty-plugin in Version 6.1.2 sondern das – Achtung – jetty-maven-plugin in Version 7.2.1.v20101111 (die Versionnummer ist kein Witz) zu verwenden. Offenbar ein Jetty Bug – anders kann ich es mir nicht erklären.

Und so sieht dann die vollständige Konfiguration aus, die bei mir dann endlich auch zum Testen schnell und komfortabel funktioniert:

<plugin>
  <groupId>org.mortbay.jetty</groupId>
  <artifactId>jetty-maven-plugin</artifactId>
  <version>7.2.1.v20101111</version>
  <configuration>
    <webAppConfig>
      <extraClasspath>${BIRT_HOME}/lib/engineapi.jar;${BIRT_HOME}/lib/coreapi.jar; \
${BIRT_HOME}/lib/modelapi.jar;${BIRT_HOME}/lib/org.apache.commons.codec_1.3.0.v20100518-1140.jar; \
${BIRT_HOME}/lib/scriptapi.jar</extraClasspath>
    </webAppConfig>
  </configuration>
</plugin>

Au weia, da hat sich o2 ja wieder nen echten FAIL geliefert: Ich hatte Anrufe von der Rufnummer +4935188815303 (also Deutschland 0351 88815303), aber immer nach 1x Klingeln, schneller als ich ans Handy gehen konnte, war der Anruf weg.

Dann hab ich mal zurückgerufen: Es ist eine O2 Nummer. Ich lande im O2 Callcenter – immerhin ist die 035188815303 ja per Festnetz Flatrate kostenlos erreichbar. Nach schier unendlichen „jetzt gleich aber wirklich tuuuut tuuuut leider doch alle im Gespräch bitte bleiben sie drann“ geht ein Callcenter Agent ran. Ich möchte wissen, was O2 von mir möchte und warum man mir keine Chance gibt, ranzugehen. „Das ist ein Systemfehler, das System wählt zu kurz an“. ACHSO! (Predictive Dailer anyone?)

Dann gebe ich meine Daten und und die gute Frau erklärt „o2 und Alice arbeiten jetzt zusammen und… “ – „nein danke bloß nicht. Hab ich auch schon 2x gesagt, dass ich bereits DSL habe. Schönen Tag noch.“

Entwickelt man mit Jetty als Servlet Container, so fällt der im Vergleich zu Glassfish relativ hohe Aufwand für Re-Deployments auf: Startet man Jetty per „mvn jetty:run“ für jedes Deployment erneut, so dauert der Neustart erst mal relativ lange, dazu geht noch die gerade aktive Session verloren. So muss man sich gegebenenfalls nach jeder Änderung bzw. jedem Restart erneut anmelden.
Das kann man relativ einfach ändern: Jetty verfügt über die Möglichkeit die Session zu persistieren – dazu müssen natürlich Session Objekte serialisierbar sein, aber das sollten diese ja sowieso sein. (Stichwort „Session migration“ und „Clustering“)
Leider findet sich auf der Jetty Homepage lediglich eine Anleitung für Jetty 6 – Jetty 7 wird nun von Eclipse weiter entwickelt und damit gehen einige Änderungen einher, für die ich hier eine Beispielkonfiguration habe:

<plugin>
<groupId>org.mortbay.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>7.2.1.v20101111</version>
<configuration>
  <webAppConfig>
    <sessionHandler implementation="org.eclipse.jetty.server.session.SessionHandler">
      <sessionManager implementation="org.eclipse.jetty.server.session.HashSessionManager">
      <storeDirectory>${basedir}/target/sessions/</storeDirectory>
    </sessionManager>
  </sessionHandler>
<contextPath>/${project.artifactId}</contextPath>
</webAppConfig>
<!--
<reload>automatic</reload>
<scanIntervalSeconds>2</scanIntervalSeconds>
<scanTargets>
<scanTarget>target/classes/</scanTarget>
</scanTargets>-->
</configuration>
</plugin>

Mit dieser Einstellung werden die Session Daten in dem Order „target/sessions“ persistiert, und man kann bei einem Neustart dort weitermachen, wo man aufgehört hat.

Schon seit einem guten Jahr nutze ich das US Tastaturlayout unter Ubuntu als Standardlayout. Gerade zum Entwickeln konnte ich wegen der besseren Position von Semikolon und geschweiften Klammern schnell einen Produktivitätsgewinn feststellen.

Doch dann kamen auch die Rückschläge: Euro Zeichen, Paragraphenzeichen (§) und Umlaute sind nicht mehr verfügbar. Für Umlaute behelfen sich einige mit Unicode Eingabe, oder Copy-Paste-Vorlagen. Ich habe mir bisher damit geholfen, dass ich die Rechtschreibkorrektur einfach „ue“ in „ü“ habe umwandeln lassen. Hilft jedoch nicht z.B. beim „§“-Zeichen.

Und da habe ich jetzt das Feature „Compose Key“ gefunden. Damit kann man – fast wie bei LaTeX – Buchstaben zusammensetzen. Dazu aktiviert man erstmal die Einstellung ein „Compose Key“ auf der Tastatur zu haben, ich habe dazu die rechte Alt-Taste verwendet. (System->Preferences->Keyboard, Layout auswählen, „Options“)

Anschließend kann man mittels <compose>-<u>, und <„> ein „ü“ zusammensetzen. Das Paragraphenzeichen geht z.B. über <compose>-<s>, <o>

Das sind Dinge, da versteh ich nicht, wie es dazu kommen kann. Wirklich nicht. Es geht um die Verbesserung des Notfalldienstes für gesetzlich (und privat) versicherte Patienten in Deutschland. Bisher ist es an mir vorbei gegangen, aber spätestens mit dieser Presseerklärung der Kassenärztlichen Vereinigung Westfalen Lippe (KVWL) ist wohl auch NRW dran: Statt bisher zum Ortstarif muss man eine 0180-5 Servicenummer anrufen, wenn man außerhalb der regulären Sprechstundenzeiten einen medizinischen Notfall hat. Der Vorteil: Die Rufnummer ist einheitlich, nicht mehr vom jeweiligen Ortsnetz abhängig.

Das war nicht immer so! Zumindest in Münster gab es verschiedene Rufnummern für die verschiedenen Bereiche, nämlich die „192 92“. Die Vorwahl konnte man wählen oder es sein lassen. Was war da jetzt uneinheitlich? Eine kurze Google Suche erweckt auch den Anschein, als sei die „19292“ relativ einheitlich verfügbar, lediglich bei manchen Gemeinden ist eine andere Rufnummer für die Fachrichtung zu wählen. Aber auch das ist nichts unmögliches – und wenn doch, wählt man eh besser die „112“. Weiterlesen »

Nicht immer genuegt es, wenn man ein Servlets auf andere Pfade oder Patterns mappt, manchmal möchte man bereits auf den Context Root ein Servlet mappen. Der übliche Work-Around sieht so aus, dass man bspw. in einer „index.jsp“ einen redirect auf eine tatsächlich einem Servlet zugeordnete URL (über den Pfad oder Datei Extension) macht, das könnte so aussehen:

<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
<c:redirect url="/myServlet"/>

Das ist aber nicht immer praktikabel – nun soll es darum gehen ein Servlet direkt auf den „/“ Pfad zu mappen – dafür gibt es mehrere Möglichkeiten:

1. Das Default Servlet ersetzen, dazu wird auf den Root Pfad „/“ in der web.xml ein Mapping angelegt:
<servlet-mapping>
<servlet-name>myServlet</servlet-name>
<url-pattern>/</url-pattern>
</servlet-mapping>
2. Ab Servlet Spezifikation kann auch ein Servlet in der welcome-file-list in der web.xml gemappt werden:
   <welcome-file-list>
<welcome-file>myServlet</welcome-file>
<welcome-file>index.html</welcome-file>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>

Im folgenden beschreibe ich die Vor- und Nachteile der verschiedenen Ansätze, und welche Erfahrungen ich mit verschiedenen Web Containern dabei gemacht habe. Weiterlesen »

Verwendet man Maven für ein Java JSP Projekt und Netbeans als IDE, so koennen erstaunliche Fehler entstehen: Um mit Servlets zu arbeiten, wird man im Maven die Abhängigkeit auf die Servlet API deklarieren. Da der Webcontainer sich später um die Implementierung der Servlets – und auch das Kompilieren von JSP Seiten – kümmert, gibt man als Scope „provided“ an.

Beispielsweise so:

<dependency>
   <groupId>javax.servlet</groupId>
   <artifactId>servlet-api</artifactId>
   <version>2.5</version>
   <scope>provided</scope>
</dependency>

Damit funktioniert die Entwicklung dann auch prinzipiell – bis auf rote Hinweise und Fehlermeldungen im Netbeans JSP Editor:

„package javax.servlet.jsp does not exist“
(cannot find symbol)

und so weiter und so fort. Bei allen JSP Direktiven, JSP Deklarationen etc. gibt es einen Hinweis darauf, dass Netbeans da etwas im Classpath fehlt. Und Netbeans hat dabei auch Recht – wenn man die JSP API nicht ebenfalls als Projekt Abhängigkeit deklariert. Hier hilft also ein kleiner Zusatz in der Maven pom.xml, der so aussehen könnte:

<dependency>
   <groupId>javax.servlet.jsp</groupId>
   <artifactId>jsp-api</artifactId>
   <version>2.1</version>
   <scope>provided</scope>
</dependency>

Hier ist die JSP Version 2.1 passend zur Servlet API 2.5 gewählt. Anschließend einmal „clean and build“ in Netbeans geklickt, und die „package javax.servlet.jsp does not exist“ Fehler sind behoben.

Eine in die Jahre gekommene Java Webanwendung, die mit dem Spring Framework (Web mvc) umgesetzt wurde, sollte ein wenig modernisiert werden. Vor allem die Umstellung auf Spring 3 und auf Annotationen basierende Controller war einiges an Migrationsarbeit.

Während des Testens viel mir auf, dass bei jedem Redeployment im Tomcat und im Glassfish 3 der Speicher knapper wurde.  Nichts sonderlich ungewöhnliches bei Java Webanwendungen. Der beste Kandidat für ein sogenanntes Permgen-Leak ist dabei der MySQL Connector (Datenbank Treiber fuer MySQL), wenn dieser mit der Webanwendung im WAR Archiv liegt, und nicht vom Container bereitgestellt wird. Durch die Art, wie sich JDBC Treiber bei Java „anmelden“ können dann Speicherlecks entstehen, wenn die Webanwendung deaktiviert bzw. redeployt wird.

Das besonders nervige an Speicherlecks, die sich auf die Permanent Generation (Permgen) auswirken, ist dass eine einzige Referenz auf den Classloader reicht, um zu verhindern dass der Garbage Collector aufräumt. Das bedeutet, dass man den Erfolg seiner Maßnahmen erst dann sieht, wenn man alle Lecks abgedichtet hat: Eine echte Geduldsprobe. Weiterlesen »