REST-Web-Services mit JAX-RS portabel aktivieren

... und dennoch implementationsspezifisch konfigurieren? Eins nach dem anderen. Seit Java EE 6 kann man JAX-RS in einem Application-Server portabel dadurch aktivieren, dass man eine Klasse von javax.ws.rs.core.Application ableitet und mit @ApplicationPath annotiert:

package com.muchsoft.rest;

import javax.ws.rs.ApplicationPath;
import javax.ws.rs.core.Application;

@ApplicationPath("/rest/*")
public class ApplicationWithRESTWebServices
                          extends Application {
}

D.h. dass man nun REST-Web-Services anbieten kann, ohne sich um die konkrete Implementierung – beispielsweise Jersey als Referenz-Implementation – kümmern zu müssen. Gut.

Was aber, wenn man doch gewisse produktspezifische Features nutzen möchte, wie beispielsweise ausführliches Trace-Logging bei Jersey? Dann greift man auf den Deployment-Deskriptor web.xml zurück und mappt dort ein Servlet mit den entsprechenden Init-Parametern. Allerdings muss das nicht eine Jersey-Klasse (mit entsprechendem servlet-mapping) sein, sondern es reicht, die eigene Application-Unterklasse als Servlet einzutragen (ohne servlet-mapping-Element):

<servlet>
  <servlet-name>
    com.muchsoft.rest.ApplicationWithRESTWebServices
  </servlet-name>
  <init-param>
    <param-name>
      com.sun.jersey.api.json.POJOMappingFeature
    </param-name>
    <param-value>true</param-value>
  </init-param>
  <init-param>
    <param-name>
      com.sun.jersey.config.feature.Trace
    </param-name>
    <param-value>true</param-value>
  </init-param>
</servlet>

REST-Web-Services mit BASIC-Auth und HTTPS in GlassFish

Nehmen wir mal einen einfachen REST-Web-Service wie den folgenden, der alle Bestellungen des Benutzers liefern soll:

@Path("/bestellungen")
public class BestellungWebService {

  @Context
  private SecurityContext securityContext;

  @Produces({ MediaType.APPLICATION_JSON,
              MediaType.APPLICATION_XML })
  @GET
  public Response getAlleBestellungen() {

    final String username =
      securityContext.getUserPrincipal().getName();

    try {
      List<Bestellung> bestellungen = ...;

      return Response.ok( bestellungen ).build();
    }
    catch (Exception e) {
      return Response.serverError()
                     .entity( e.getMessage() ).build();
    }
  }
}

Mit beispielsweise Wget könnte dieser Service dann wie folgt aufgerufen werden, wenn der Applikationspfad auf "rest" gemappt ist:

wget http://localhost:8080/meinewebapp/rest/bestellungen

Fast immer muss ein solcher Service abgesichert werden, damit nur bestimmte Anwender Zugriff darauf haben. Man könnte natürlich den UserPrincipal programmatisch auswerten, aber sofern die berechtigten Benutzer im Application-Server als User eingetragen sind, ist eine deklarative Absicherung einfacher - und erfordert keine Änderungen am Quelltext.

Am Beispiel von GlassFish 3.1.2 schauen wir uns das an. Wir erlauben dem GlassFish-Admin-User, den Web-Service aufzurufen. Dazu sichern wir am Ende des Deployment-Deskriptors web.xml alle Ressourcen unterhalb /rest so ab, dass nur die "admin"-Rolle darauf zugreifen darf. Mit CONFIDENTIAL erzwingen wir zudem, dass die Übertragung der Daten per https (SSL bzw. TLS) stattfindet:

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
    http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
    version="3.0">

  ...

  <security-constraint>
    <web-resource-collection>
      <url-pattern>/rest/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
      <role-name>admin</role-name>
    </auth-constraint>
    <user-data-constraint>
      <transport-guarantee>CONFIDENTIAL</transport-guarantee>
    </user-data-constraint>
  </security-constraint>

  <login-config>
    <auth-method>BASIC</auth-method>
    <realm-name>admin-realm</realm-name>
  </login-config>

  <security-role>
    <role-name>admin</role-name>
  </security-role>

</web-app>

Die BASIC-Authentication, bei der Benutzername und Passwort im Klartext (!) übertragen werden, ist hier dennoch in Ordnung, weil wir gleichzeitig mit https die verschlüsselte Datenübertragung aktivieren.

Die berechtigten Anwender müssen im "admin-realm" eingetragen sein, das ist der Realm mit allen GlassFish-Admins (der in der Standardinstallation den User "admin" enthält). Als Beispiel für einen Security-Realm ist das hier ausreichend; in der Praxis wird man aus Sicherheitsgründen eher einen separaten Realm im GlassFish konfigurieren und in web.xml referenzieren.

Nun müssen wir dem Application-Server noch – produktspezifisch – mitteilen, welche Benutzernamen aus dem Realm auf welche Rollen gemappt werden. Dies erfolgt in der Datei glassfish-web.xml (früher sun-web.xml):

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE glassfish-web-app PUBLIC
  "-//GlassFish.org//DTD GlassFish Application Server 3.1 Servlet 3.0//EN"
  "http://glassfish.org/dtds/glassfish-web-app_3_0-1.dtd">
<glassfish-web-app>

  <context-root>meinewebapp</context-root>
     
  <security-role-mapping>
    <role-name>admin</role-name>
    <principal-name>admin</principal-name>
  </security-role-mapping>

</glassfish-web-app>

Fertig. Der Aufruf des Web-Services erfolgt über Wget nun mit

wget https://localhost:8081/meinewebapp/rest/bestellungen
       --user ... --password ... --no-check-certificate

Ein Aufruf über unverschlüsseltes http ist nicht mehr möglich. Während wir hier der Einfachheit halber auf die Prüfung des https-Zertifikats verzichten, sollte man in der Praxis besser ein geeignetes eigenes Zertifikat im Server installieren und auf Client-Seite verwenden.

JAXB und HashMaps, Teil 2

In Teil 1 zu JAXB und HashMaps ging es vor einiger Zeit darum, mit möglichst wenig Aufwand im Java-Code eine XML-Struktur zu verarbeiten, deren Element-Namen teilweise fest vorgegeben waren. Teil 2 zeigt nun, wie man eine XML-Struktur mit beliebigen Element-Namen aus einer (Hash)Map innerhalb einer JAXB-Entität ausgibt (bzw. dorthin einliest). Konkret soll folgendes XML-Dokument erzeugt werden:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<meineEntitaet>
  <paarliste>
    <paar>
      <schluessel>Antwort</schluessel>
      <wert>42</wert>
    </paar>
  </paarliste>
</meineEntitaet>

Dazu benötigen wir als Erstes für einen einzelnen Eintrag der Map (also für jedes Schlüssel-Wert-Paar) folgende Klasse:

import javax.xml.bind.annotation.XmlElement;

class MapElement {

  @XmlElement(name = "schluessel")
  String key;

  @XmlElement(name = "wert")
  Integer value;

  MapElement() {
  }

  MapElement(String key, Integer value) {
    this.key = key;
    this.value = value;
  }
}

Die Liste der Map-Einträge wird in einer eigenen Klasse verpackt, damit wir den Namen des XML-Elements festlegen können, das die einzelnen Schlüssel-Wert-Paare umschließt:

class MapElements {

  @XmlElement(name = "paar")
  List<MapElement> mapElements;

  MapElements() {
  }

  MapElements(List<MapElement> mapElements) {
    this.mapElements = mapElements;
  }
}

In der JAXB-Entität taucht nun aber nicht diese MapElements-Klasse auf, sondern die ursprünglich gewünschte (Hash)Map:

import java.util.*;
import javax.xml.bind.annotation.*;

@XmlRootElement
@XmlAccessorType(XmlAccessType.FIELD)
public class MeineEntitaet {

  @XmlElement(name = "paarliste")
  @XmlJavaTypeAdapter(MapAdapter.class)
  private Map<String, Integer> map = new HashMap<>();
  public Map<String, Integer> getMap() {
    return map;
  }

  public void setMap(Map<String, Integer> map) {
    this.map = map;
  }
}

Für die Umwandlung zwischen der MapElements-Klasse und der HashMap benötigen wir einen XmlAdapter:

import java.util.*;
import javax.xml.bind.annotation.adapters.XmlAdapter;

public class MapAdapter extends XmlAdapter<MapElements, Map<String, Integer>> {

  @Override
  public MapElements marshal(Map<String, Integer> map) {
    List<MapElement> list = new ArrayList<>();
    for (Map.Entry<String, Integer> entry : map.entrySet()) {
      list.add(new MapElement(entry.getKey(), entry.getValue()));
    }
    return new MapElements(list);
  }

  @Override
  public Map<String, Integer> unmarshal(MapElements elements) {
    Map<String, Integer> map = new HashMap<>();
    for (MapElement mapElement : elements.mapElements) {
      map.put(mapElement.key, mapElement.value);
    }
    return map;
  }
}

Damit können wir schließlich das XML-Dokument erzeugen:

MeineEntitaet huelle = new MeineEntitaet();
huelle.getMap().put("Antwort", 42);
JAXB.marshal(huelle, System.out);

Warum ist StandardCharsets final?

In vielen Anwendungen und Bibliotheken findet man eine Klasse, die Konstanten für häufig benutzte Zeichensätze enthält:

import java.nio.charset.Charset;

public class ApplicationCharsets {

  public static final Charset UTF_8

    = Charset.forName( "UTF-8" );

  public static final Charset ISO_8859_1

    = Charset.forName( "ISO-8859-1" );

  public static final Charset WINDOWS_1252

    = Charset.forName( "WINDOWS-1252" );

} 

Seit Java 7 gibt es die Klasse java.nio.charset.StandardCharsets, die Konstanten für die Zeichensätze enthält, die garantiert in jeder Java-Implementierung zur Verfügung stehen – US-ASCII, ISO-8859-1 (ISO Latin 1) sowie diverse Unicode-Kodierungen.

Damit man im Anwendungs-Code nicht verschiedene Klassen für die Standard- und die Anwendungs-Zeichensatzkodierungen referenzieren muss, könnte man die Anwendungs-Konstanten wie folgt formulieren ...

import java.nio.charset.*;

public class ApplicationCharsets

    extends StandardCharsets /* geht nicht :-( */ {

  public static final Charset WINDOWS_1252

    = Charset.forName( "WINDOWS-1252" );

} 

... wenn die Klasse StandardCharsets nicht final wäre. So bleibt derzeit leider nur folgender Ausweg:

public class ApplicationCharsets {

  public static final Charset UTF_8

    = StandardCharsets.UTF_8;

  public static final Charset ISO_8859_1

    = StandardCharsets.ISO_8859_1;

  public static final Charset WINDOWS_1252

    = Charset.forName( "WINDOWS-1252" );

} 

Warum also darf von StandardCharsets keine Unterklasse abgeleitet werden? Einfach nur aus historischen Gründen, weil ähnliche Klassen bisher auch final waren? Kann man das in Java 8 ändern?

Wie Apple riskante Java-Versionen mit der Xprotect-Liste deaktiviert

Am 1. Februar hat Oracle mit Java 7u13 und Java 6u39 zwei Updates veröffentlicht, die diverse sicherheitskritische Lücken geschlossen haben. Anwender von Mac OS X 10.6, 10.7 und 10.8 haben dies vielleicht schon einen Tag früher erahnen können, denn am 31. Januar hat Apple alle bis dahin gültigen Java-Versionen – zumindest die Applet-Nutzung – deaktiviert.

Nun sind Java-Applets zwar nicht mehr der Stand der Dinge, aber diverse Anwendungen laufen nicht ohne sie (einige VPN-Clients, elektronische Steuererklärung etc.). Und wer beruflich oder privat darauf angewiesen ist und einen Tag lang nicht weiß, warum die Web-Anwendung plötzlich nicht mehr funktioniert (gestern tat sie es ja noch!), steht erst einmal auf dem Schlauch...

Unabhängig von der Frage, ob es eine kluge Entscheidung war, die Java-Versionen zu deaktivieren, bevor entsprechende Updates zur Verfügung standen – wie hat Apple die Deaktivierung der Java-Applets realisiert?

Dazu gibt es im System die Datei /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta.plist mit derzeit folgendem Inhalt (XML-Prolog etc. leicht gekürzt):

<dict>
  <key>JavaWebComponentVersionMinimum</key>
  <string>1.6.0_37-b06-435</string>
  <key>LastModification</key>
  <string>Fri, 08 Feb 2013 00:54:09 GMT</string>
  <key>PlugInBlacklist</key>
  <dict>
    <key>10</key>
    <dict>
      <key>com.macromedia.Flash Player.plugin</key>
      <dict>
        <key>MinimumPlugInBundleVersion</key>
        <string>11.5.502.149</string>
      </dict>
      <key>com.oracle.java.JavaAppletPlugin</key>
      <dict>
        <key>MinimumPlugInBundleVersion</key>
        <string>1.7.11.22</string>
      </dict>
    </dict>
  </dict>
  <key>Version</key>
  <integer>2029</integer>
</dict>

Die angegebenen Versionsnummern beziehen sich auf die Java Runtime Version, und die waren Ende Januar noch 1.6.0_37-b06-434 bzw. 1.7.0_11-b21. Apple hat die erforderliche Version also minimal über die verfügbaren Versionen gesetzt und damit die Applet-Plugins blockiert.

Wenn man auf das Arbeiten mit einer solchen, als gefährlich eingestuften Java-Version angewiesen ist und weiß, was man tut, kann man die Xprotect-Liste mit

sudo pico /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta.plist

bearbeiten und den Minimum-Wert auf die installierte Java-Runtime-Version setzen. Sollten die Java-Bugfix-Updates dann längere Zeit ausbleiben, könnte man noch überlegen, das Aktualisieren der XProtect-Liste auszuschalten (in den Systemeinstellungen / Sicherheit / Weitere Optionen...), damit man die manuelle Änderung nicht jeden Tag durchführen muss. Aber Achtung, diese Option bezieht sich nicht nur auf Java-Versionen, sondern auch auf Flash und eventuelle Malware-Downloads!

OS X 10.8, Java und X11

Es gibt Java-Anwendungen, die X11 verwenden. Bei mir ist dies z.B. ein VPN-Client-Applet, was ich allerdings erst durch folgenden Hinweis erfahren habe:

In OS X 10.8 wird nicht nur Java nicht mehr vorinstalliert, auch X11 ist als Komponente, die "normale" Anwender nicht benötigen, nicht mehr vorhanden ...

Klickt man in dem Dialog auf "Fortfahren", wird man auf eine Apple-Support-Web-Seite gebracht, auf der man die Hintergründe zum XQuartz-Open-Source-Projekt erfährt. Dort kann man dann auch eine aktuelle Version (mind. 2.7.2, getestet habe ich 2.7.4) herunterladen, mit der OS X "Mountain Lion" und Java glücklich werden.

Die Installation von X11 löst ein weiteres Problem: Das GlassFish-Installations-Shellskript meldet unter OS X 10.8 folgenden Fehler:

much$ ./glassfish-3.1.2.2-unix.sh 
This program requires DISPLAY environment variable to be set.
Please re-run after assigning an appropriate value to DISPLAY.

Nach der Installation von X11 und einem Aus- und Einloggen ist die Umgebungsvariable "DISPLAY" wieder korrekt gesetzt und das Installations-Skript funktioniert wie gewohnt.

Apples Java-Update 2012-006 und die Sache mit dem Browser-Applet-Plugin

Zeitgleich haben Apple und Oracle Anfang vergangener Woche die neuesten Java-Updates veröffentlicht (Oracle: JDK und JRE 7u9; Apple: Java 6u37). Dieser Blog-Eintrag fasst zusammen, was ich bereits im Usenet geschrieben habe bzw. was Oracle als Hinweise dazu veröffentlicht hat.

Bisher war es so, dass in den Mac-Web-Browsern immer Apples Java-Applet-Plugin (also Java 6) aktiv war – es sei denn, man hatte Oracles JRE 7 installiert, dann wurde genau dieses Java 7 als Applet-Plugin verwendet.

Mit dem neuen Update "Java for OS X 2012-006" für Mac OS X 10.7 und 10.8 entfernt Apple das Java-6-Applet-Plugin nun explizit aus dem System. D.h. nach der Installation des Java-Updates ist zunächst einmal kein Applet-Plugin mehr verfügbar. Stattdessen wird auf einer Web-Seite, die ein Applet einbindet, die Meldung "Fehlendes Plug-In" angezeigt:

Klickt man auf die Meldung, erscheint ein etwas ausführlicherer Hinweis:

Dort bringt einen der Klick auf "Weitere Infos ..." auf Oracles Mac-JRE-Download-Seite. Apple drängt die Anwender also recht eindeutig zum Upgrade auf Java 7, was angesichts von wichtigen Security-Bugfixes, die es für Java 6 bald nicht mehr geben wird, mehr als verständlich ist.

Leider kommen einige wenige Java-Applets noch nicht mit Java 7 zurecht. Manche verweigern z.B. aufgrund schlechter bzw. zu restriktiver Programmierung (fest kodierte Prüfung einer bestimmten Java-Versionsnummer o.ä.) den Dienst mit der seit über einem Jahr aktuellen Java-Version... Wer auf die Arbeit mit so einem Applet angewiesen ist, kann das alte Plugin manuell im Terminal reaktivieren. Im Wesentlichen läuft das darauf hinaus, den Symlink /Library/Internet Plug-Ins/JavaAppletPlugin.plugin auf das noch vorhandene, aber gut versteckte /System/Library/Java/Support/Deploy.bundle/Contents/Resources/JavaPlugin2_NPAPI.plugin zeigen zu lassen (das ebenfalls vorhandene /System/Library/Java/Support/CoreDeploy.bundle/Contents/JavaAppletPlugin.plugin ist mit dem Update 2012-006 kein vollwertiges Applet-Plugin mehr, sondern zeigt nur noch den Hinweis zum fehlenden JRE7-Plugin an, s.o.).

Apples Java-Update 2012-006 löscht zudem die Java-Einstellungen in den Dienstprogrammen. Das Java Control Panel in den Systemeinstellungen ist damit die einzige Möglichkeit, Laufzeitparameter für Applets festzulegen. Schwerwiegender dürfte aber sein, dass Entwickler damit die bisher unter Mac OS X sehr einfache grafische Möglichkeit verlieren, aus allen installierten JDKs die aktive Version für die Kommandozeile auszuwählen. Stattdessen wird von den Kommandozeilentools in /usr/bin das JDK mit der höchsten Nummer verwendet. Was so einfach klingt, kann durchaus zu Problemen führen, wenn Vorabversionen des JDKs installiert sind:

HeartOfGold:~ much$ which java
/usr/bin/java
HeartOfGold:~ much$ java -version
openjdk version "1.8.0-b50"
OpenJDK Runtime Environment (build 1.8.0-b50-20120801)
OpenJDK 64-Bit Server VM (build 24.0-b16, mixed mode)

Glücklicherweise beachten die Tools die Umgebungsvariable JAVA_HOME, die man in seinen Shell-Skripten mithilfe des – schon längere Zeit verfügbaren – OSX-Tools /usr/libexec/java_home passend setzen kann:

HeartOfGold:~ much$ export JAVA_HOME=`/usr/libexec/java_home -v 1.7`
HeartOfGold:~ much$ printenv JAVA_HOME
/Library/Java/JavaVirtualMachines/jdk1.7.0_09.jdk/Contents/Home
HeartOfGold:~ much$ java -version
java version "1.7.0_09"
Java(TM) SE Runtime Environment (build 1.7.0_09-b05)
Java HotSpot(TM) 64-Bit Server VM (build 23.5-b02, mixed mode)

Alternativ kann man das java_home-Tool dazu verwenden, ein (Java-)Kommando mit einer bestimmten Java-Version auszuführen:

HeartOfGold:~ much$ /usr/libexec/java_home -v 1.6 --exec java -version
java version "1.6.0_37"
Java(TM) SE Runtime Environment (build 1.6.0_37-b06-434-11M3909)
Java HotSpot(TM) 64-Bit Server VM (build 20.12-b01-434, mixed mode)