jtb.blog

Meine ehemalige Uni hat ein nettes System im Probebetrieb gestartet: Webtasks
Idee hinter dem System ist, dass angehende Stundenten kleine Programmieraufgaben und Wissenstests online lösen können. Zwar noch stellenweise recht buggy, aber vom Ansatz her wirklich geil.

Interessant für fortgeschrittene Programmierer ist hierbei die eingehende Analyse des System bzw der Absicherung
Viel Spaß beim Lesen der folgenden Seiten

Sowas müssen sich die Leute gedacht haben, die sich die Konfigurationsstruktur von Tomcat ausgedacht haben.
Die ganze Konfiguration baut auf XML auf (solange eine Anwendung sich nicht denkt, weitere Einstellungen über eine Properties-Datei zu machen). Eigentlich eine nette Idee - so kann der Server die Datei leichter parsen. Nur für den Menschen wird die Datei sehr leicht kaum noch lesbar. Es gibt zwar eine Administrationsoberfläche, aber die erwies sich bei meinen Versuchen mit Tomcat dieses Wochenende als unbrauchbar. Ich wollte ja eigentlich mal jboss ausprobieren, aber jboss ist leider unter Gentoo stable gerade nicht installierbar und mir wurde von der Benutzung in Gentoo im #gentoo-java Channel abgeraten. Aber zurück zu Tomcat. Für die gerade erwähnte Administrationsoberfläche muss man sich erstmal von Hand einen User angelegen. Dessen Passwort steht dann erstmal im Klartext in der Datei. Gehashte Passwörter unterstützt Tomcat nicht in einer Passwortdatei - das klappt nur mit einer Datenbank (per jdbc) bzw Verzeichnisdienst wie LDAP. Ein nicht zu unterschätzender Aufwand. Denkt man sich nun, dass man ja die Passwortdatei nur vom Serveruser (also beispielsweise tomcat) lesbar/schreibbar machen kann, wird man von der Administrationsoberfläche sanft auf den Boden der Wirklichkeit zurückgeholt: ändert man einen User, wird die Datei wieder world-readable gemacht
Bei den verfügbaren Webanwendungen, die ich mir angeguckt habe, wurde in der Installationsdokumentation immer die Konfiguration in XML angegeben - also muss ich als Administrator meine Konfig jetzt in einem Format tippen, was eigentlich dafür gedacht ist, maschinenlesbar zu sein

Aber ansonsten hat die Adminoberfläche so einige Tücken. Ich finde es zwar schön, dass man sich mit ein paar Klicks einen Vhost anlegen kann, vermisse aber dann die Zuordnung von Prioritäten. Weiterhin kann man scheinbar keinen Alias mit einem Wildcard erstellen (also *.domain.tld um alle Subdomains abzufangen). Bzw der Alias wird ohne Fehler erstellt und zeigt keine Wirkung. Wenn schon kein Alias erlaubt ist, dann müsste eigentlich die fehlerhafte Eingabe abgefangen werden.

Gibt man einen Vhost im Browser ein, den es nicht gibt, wird der Browser nur eine leere Seite anzeigen - erst ein Blick in die Header der Antwort ergibt:

Diese Fehlermeldung kommt übrigens auch, wenn man keinen Context für den Vhost eingerichtet hat - sehr angenehm zum testen
Wieso man in der Adminoberfläche weniger wesentlich weniger Attribute angeben kann als möglich, will ich garnicht wissen.

Sehr schamant fand ich auch folgenden "Bug": man lad eine WAR-Datei hoch, die dann vom Tomcat entpackt werden sollte. Dieser macht es nicht und äußert sich im Log nur, dass er das Verzeichnis WEB-INF nicht finden kann. Was irgendwie logisch ist, wenn nichts entpackt wurde.
Lösung: tomcat hatte nicht die Schreibrechte auf den Ordner, so dass die WAR-Datei nicht entpackt werden konnte. Es kam aber kein Fehler dazu, so dass ich lange rumsuchen musste
Ich vermute einfach mal, dass dort das Ich-Muss-Alle-Exceptions-Fangen Paradigma von Java zugeschlagen hat..

Bei meiner Installation einer anderen Java-Software kam es zu weiteren Fehlern. Für die Anwendung Roller muss man einen Context anlegen und in diesem die Datenbankverbindung konfigurieren. Das Problem: sobald man den Context anlegt, kommt man in der Administrationsoberfläche nicht weiter - es kam der Fehler "Document base does not exist or is not a readable directory.". In den Logfiles von Roller fand ich aber den Hinweis, dass die Anwendung schon versuchte, die Datenbankverbindung aufzubauen... Also die Konfigurationsdatei des Contexts von Hand editiert und schon funktionierte alles.. Aber zum Thema Logfiles lesen: wenn ich keinen Debugmodus angeschaltet habe, möchte ich keinen über 20-zeiligen Stacktrace bekommen. Da sieht man ja die Fehlermeldung vor lauter Methodenaufrufen nicht mehr!

Weiterhin hat die Adminoberfläche scheinbar Probleme mit einem Context, dessen Appbase manuell gelöscht wurde:

Davon, dass ich in die Administrationsoberfläche nach einmaligen Anlegen weder Path noch Docbase ändern kann, will ich garnicht erst reden


Danke, mir reicht's erstmal mit Tomcat




Wann ist endlich Mono so weit, dass ich ASP.Net 2 unter Linux einsetzen kann?
Oder es endlich Dedicated Server Angebote mit genug RAM gibt, so dass man dank Virtualisierung sowohl Linux als auch Windows fahren kann?

Mal wieder ein schönes Beispiel zum Thema Programmieren an der Uni. Aufgabe war die Implementierung einer HashTable in Java. Schon die Angabe der verschiedenen Modi der HashTable über Strings brachte mich arg zum stauen (wo es doch in Java 5 so schöne Enumerations gibt und man damit sich kostenlos Schutz durch den Compiler erkauft).
Aber das Beste war die Verwendung eines Interfaces. Man bekam ein Interface namens EntryInterface gestellt und musste nun eine Klasse namens Entry unter Verwendung dieses Interfaces implementieren.
Moment – Warum ist der Klassenname Entry vorgegeben?
Wir haben doch eine schön definierte Schnittstelle und die mitgelieferten Testcases können doch einfach diese nutzen. Dank Interface habe ich ja ein Abstraktionslayer, so dass die reelle Implementierung von EntryInterface niemanden außer dem Entwickler der HashTable-Interna interessieren sollte.
Beim näheren Anschauen der Testcases lief dann auf, dass diese eine Instanz von Entry benötigen:


Es hat schon einen guten Grund, warum die HashTable in Java anders implementiert ist. Dort muss man nicht ein Objekt übergeben, sondern direkt Key und Data. Eine Klasse weniger nötig zum Benutzen.
Ein Interface auf eine solche Art zu benutzen ist schon arg komisch. Da gibt es nun wirklich bessere Lösungen..

Für einen kleinen Dienst auf der Arbeit habe ich einen Webservice gebaut (klar, die Vorteile sprechen für sich: eingebaute Verschlüsslung dank https und Zugriff von fast überall).
Da der Client auch in C# 2005 geschrieben werden sollte (man will ja mal die neuen Features ausprobieren), habe ich den Webservice natürlich auch gleich in dotNet geschrieben - geht ja auch schön leicht: ein paar Klicks und fertig ist das ganze im Visual Studio 2005.

Getestet und nun kommt das Problem des Deployments - auf dem passenden Server ist zwar nicht ein, nicht zwei sondern schon drei Webserver installiert (Apache2+Tomcat und Lotus Domino).. Upps, da fehlt IIS...
na ja, als Workaround schnell mal einen IIS installiert und eingerichet, aber wirklich toll ist es nicht.

Also der Plan: den Server-Teil neu in Java programmieren. In der Theorie kein Problem, in der Praxis aber schon. Das generierte WSDL vom dotnet-Webservice will die WTP-Extension von Eclipse nicht als korrekt validieren.

Also alles aus der WSDL-Datei entfernen (eigentlich nur SOAP12) - und die Validierung klappt.
Nun merkt man, dass es nicht (so einfach) wie bei dotNet möglich ist einen SoapHeader zu definieren und in Implementierung anzusprechen..

Nur mal als Beispiel wie einfach das mit dotNet 2.0 ist:

[WebService(Namespace = "http://mydomain.tld/")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
public class TrackerWebservice : System.Web.Services.WebService
{
public SoapAuthenticationHeader authentication;

public TrackerWebservice()
{}

[WebMethod(Description = "Adds a trackerentry to the tracker", EnableSession = false)]
[SoapHeader("authentication")]
public void addEntry(Entry entry)
{
/* implementation */
}
// [..]

und

public class SoapAuthenticationHeader : SoapHeader
{
private NetworkCredential credentials;

public NetworkCredential Credentials
{
get { return credentials; }
set { credentials = value; }
}

}