UNIXwork

Es kommt des Öfteren vor, dass man einen Netzwerk-Service testen, oder allgemein mit einer Anwendung über Sockets kommunizieren möchte. Viele verwenden dafür telnet, jedoch ist das eine Zweckentfremdung des Programms. Telnet ist eigentlich ein Fernwartungstool, das heute nur noch selten eingesetzt wird, weil es unsicher ist. Der Telnet-Client kann aber für die meisten textbasierten Protokolle verwendet werden. Z.B. wird telnet manchmal verwendet, um manuell einen HTTP-Request auszuführen. Es gibt jedoch ein Tool, was genau für solche Zwecke gedacht ist, nämlich netcat, das oft als "TCP/IP swiss army knife" bezeichnet wird. Netcat kann natürlich mehr als nur die Standardeingabe zum Server zu schicken und die Antworten auszugeben. Es unterstützt unter anderem auch UDP, es kann als Server verwendet werden und im Gegensatz zu telnet kann netcat mit Pipes und Redirections umgehen.

Ein typischer Anwendungsfall ist, dass mit netcat eine Verbindung zu einem Server aufgebaut wird, die Standardeingabe von Netcat an den Server geschickt wird und die Antwort vom Server ausgegeben wird. Im folgendem Beispiel wird eine Verbindung zu einem Webserver hergestellt und ein HTTP-Request abgeschickt.

$ nc unixwork.de 80
GET / HTTP/1.1
Host: unixwork.de

HTTP/1.1 307 Temporary Redirect
Server: Apache-Coyote/1.1
Location: /blog/
Content-Type: text/html;charset=ISO-8859-1
Content-Length: 0
Date: Wed, 05 Nov 2014 20:14:29 GMT

...

Ein weiteres und komplexeres Beispiel sei der Wikipedia entlehnt:

{ echo -ne "HTTP/1.0 200 OK\r\n\ 
Content-Length: $(wc -c < some.file)\r\n\r\n";\ 
cat some.file; } | nc -l 8080

Fertig ist ein kleiner Webserver, der eine Datei überträgt.

Es gibt mitlerweile viele Varianten von netcat, unter anderem auch welche, die SSL unterstützen. Für Windows ist netcat ebenfalls erhältlich.

Möchte man, dass eine Java-Webanwendungen auf verschiedenen Applicationservern oder Servletcontainern lauffähig ist, gibt es im Bezug auf JNDI einen kleinen Fallstrick. Die JNDI-Namen für Resourcen sind nämlich nicht überall gleich. Mit folgendem Code kann man unter Glassfish auf einen vom Applicationserver zur Verfügung gestellten Connection-Pool zugreifen:

InitialContext context = new InitialContext();
DataSource dataSource = (DataSource) context.lookup("jdbc/mydb");
Connection connection = dataSource.getConnection();

Mit anderen Servern, wie z.B. Apache Tomcat, funktioniert dies jedoch nicht. Statt dem String "jdbc/mydb" müsste man dort "java:comp/env/jdbc/mydb" verwenden. Das wiederum funktioniert nicht mit Glassfish, zumindestens nicht ohne weiteres. Allerdings gibt es dafür eine Lösung.

Man verwendet folgenden Java-Code.

DataSource dataSource = (DataSource) context.lookup("java:comp/env/jdbc/mydb");

Dazu muss man dann noch den Standard Deployment Descriptor web.xml und die glassfish-web.xml anpassen. In die web.xml wird folgendes eingefügt:

<resource-ref>
    <res-ref-name>jdbc/mydb</res-ref-name>
    <res-type>javax.sql.DataSource</res-type>
    <res-auth>Container</res-auth>
    <res-sharing-scope>Shareable</res-sharing-scope>
</resource-ref>

und in die glassfish-web.xml das:

<resource-ref>
    <res-ref-name>jdbc/mydb</res-ref-name>
    <jndi-name>jdbc/mydb</jndi-name>  
</resource-ref>

Danach funktioniert die Webapp sowohl mit Glassfish als auch mit Tomcat, wenn im Server die nötigen JNDI-Resourcen konfiguriert sind.