Was ist eigentlich Rückwärtskompatibilität?

von Roman Seibold

Ein furchtbar schwer auszusprechendes Wort, mehr nicht, wie ich dieser Tage erfahren musste. Hintergrund war die "schnelle und einfache" Umstellung eines Servers, auf dem bislang JBoss 5.1 betrieben wurde. Bei der Umstellung sollte gleich die JBoss-Version auf die aktuelle 6.0 migriert werden.

Auf JBoss 5.1 lief eine Anwendung, die seit vielen Jahren auf div. Servern u.a. auch auf JBoss 5.0, Tomcat 5.x und IBM WebSphere Application Server 5 und 6, gelaufen ist. Zu Beginn als reine Web-Anwendung, seit der Migration auf JBoss 5.x auch als echte 3-Tier-Applikation mit EJBs.

Nie, ich betone "nie", gab es Probleme bei der Migration. Einfach neuen Server installieren, konfigurieren (Datasources, Queues usw.) und Anwendung deployen, fertig. Jetzt, mit JBoss 6, wurde alles anders.

Das Kernproblem war, dass die Anwendung, schon leicht in die Jahre gekommen, das damals sehr populäre Struts 1 verwendet. Und Struts 1 läuft in unveränderter Form nicht auf JBoss 6. Ja, Sie haben richtig gelesen. Da Struts 1 nicht mehr weiterentwickelt wird und Struts 2 jetzt nicht wirklich einfach eine aktuellere Version ist, sondern schon etwas anderes, gibt es da auch keinen Migrationspfad.

Symptom, dass die Anwendung nicht mehr läuft, sind Deployment-Errors, die auf nicht korrekte URIs hinweisen (z.B. in bsf-2.3.0.jar). Es wird von JBoss 6 moniert, dass "http://java.sun.com/j2ee/dtds/web-jsptaglib_1_1.dtd" nicht existiere. Das ist im Grunde genommen auch richtig, denn der URI in der Taglibrary-Definition sollte "http://java.sun.com/j2ee/dtds/web-jsptaglibrary_1_1.dtd" heissen (d.h. "jsptaglibrary" statt "jsptaglib"). Allerdings fragt man sich, wieso so etwas bislang auf allen Servern anstandslos gelaufen ist und nur der neue JBoss hier Probleme bereitet. Angeblich, weil JBoss etwas strikter im Umgang mit XML-Validierung geworden ist.

Die Lösung für dieses Problem ist zwar einfach, aber irgendwie nicht akzeptabel:
man extrahiert bsf-2.3.0.jar, editiert unter META-INF/taglib.tld die Datei und
ersetzt den obigen String mit seiner korrekten Version. Danach packt man das JAR wieder zusammen und ersetzt das alte. Fehler beseitigt.

Danach wird sich herausstellen, dass die Applikation wieder startet, aber nicht in allen Fällen funktioniert. Es kommt zu JSP-Compile-Fehlern. Nach längerem, scharfen Hinsehen entdeckt man, dass einige Struts-Tags in den JSPs das Problem verursachen. Nämlich solche Kandidaten wie <html:select> oder <html:option>.
Diese Tags haben Inhalt (aka "body-content"), bei option z.B. die Beschriftung, wenn sie denn nicht aus einem Ressource-File kommt. In der TLD dieser Tags fehlt aber der Hinweis auf den "body-content". Wenn man zu diesem Konfigurationseintrag etwas näher in der JSP-2.1-Spezifikation stöbert, kommt man zu dieser Stelle (S. 3-37, JSP-Spec 2.1):

"body-content: Specifies the format for the body of this tag. The default in JSP 1.2 was 'JSP' but because this is an invalid setting for simple tag handlers, there is no longer a default in JSP 2.0."

Das heißt, weil in der Tag-Library-Angabe der body-content fehlt, quittiert die JBoss 6-JSP-Runtime diese Tags mit einem Compile-Fehler, allerdings ohne sinnvolle Fehlerangabe. Man sieht nur NullPointerExceptions.

Die Lösung ist auch hier so simpel wie unverzeihlich: analog zum oben erwähnten Vorgehen bei der bsf.jar muss man die Datei struts-taglib-1.3.10.jar (Struts 1.3.10 vorausgesetzt natürlich) von Hand ändern, genauer gesagt die Datei META-INF/tld/taglib.tld, und überall wo der Autor dieser Datei davon ausging, wenn er body-content nicht angibt, dass dann der Default "JSP" zieht, ein explizites

<body-content>JSP</body-content>

einfügen. Das wars "auch schon". Man muss nur darauf kommen.

Abschließend kann man eigentlich nur resignierend resümmieren, dass es ja schön ist, wenn JBoss sich an die Spezifikationen hält und dass es natürlich nicht schön von Sun/Oracle ist, Defaults nachträglich zu entfernen. Aber es ist schon komisch, dass sich beispielsweise die letzte JBoss-Version 5.1, die auch schon JSP 2.1 implementiert hat, daran nicht störte.

Ist das vielleicht auch der Unterschied zwischen Open-Source-Software und den (oftmals teuren) Produkten großer Hersteller?