tomcat

[Christoph Schnauß]

hallo Leute ;-)

Ich hab ja geglaubt, daß ich so langsam, ganz langsam, ungefähr verstanden habe, was der Apache kann  -  egal, auf welcher Plattform. Und so hab ich mich jetzt entschlossen, mal bissel weiter zu schauen und mich um ein paar andere Projekte der Apache Group zu kümmern  -  ich bin halt schon mehrfach gefragt worden, ob ich was zu Tomcat weiß.

Bisher wußte ich allerdings nicht viel mehr, als daß es ein Subprojekt der Apache Group ist. Und weil ich JSP eh nicht besonders mag (und wohl auch immer noch nicht _richtig_ damit umgehen kann) hab ich das bisher beiseitegeschoben.  Na gut, jetzt hab ich versucht, mir das Teil doch mal zu installieren, weil ich zunehmend gefragt worden bin, was das denn ist (seufz). Aber ich komme damit nicht zurecht.

Ich habs erstmal mit einer Installation unter WinP versucht  -  wenn ich den Rechner bzw. die Festplatte, auf der das läuft, aus Versehen zerschießen sollte, ist es nicht ganz so schlimm *g*. Von http://www.apache.de/dist/jakarta/tomcat-4/binaries/ hab ich mir die Installationsdatei gezogen, das ging alles reibungslos -  ja, aber was hab ich jetzt von dem Teil?

Mich irritiert, daß auf http://jakarta.apache.org bereits auf eine ganze lange Liste von "SubProjcts" verwiesen wird. Ich kann mit diesen Unterprojekten nix anfangen, und ich verstehe das, was ich bei allen diesen Teilen als FAQ/Readme/Help gefunden habe, wohl nicht richtig. Ja doch, was ich an "Anleitungen" bisher erhaschen konnte, hab ich einigermaßen studiert  -  aber ich kann mit dem ganzen Ding immer noch nix anfangen, weil ich nicht weiß, wozu es nun eigentlich gut ist.

Selbstverständlich ist ein lokaler Apache bereits installiert, und selbstverständlich gibts auch eine lokale JAVA-Installation, die gut funktioniert.

Was spricht eigentlich dafür, sich mit JSP zu beschäftigen und tomcat zu installieren/administrieren?

Wie sind diese Subprojekte zu verstehen, welche braucht man davon  -  und wofür braucht man sie (bitte: auf die englischsprachige Doku zu verlinken, bringt mir nix, weil ich die sehr wohl gelesen, aber bestimmt nicht richtig verstanden habe)?

Grüße aus Berlin

Christoph S.

[Simon Reinhardt]

Hi!

Was spricht eigentlich dafür, sich mit JSP zu beschäftigen und tomcat zu installieren/administrieren?

Zu der zweiten Frage: Tomcat ist die Referenz-Implementation der Java Servlet Specification und der JavaServer Pages Specification. Heißt im Klartext: es ist der Standard-Container für Servlets und JSP's. Was jetzt also dafür spricht, gerade Tomcat zu installieren, ist eine andere Frage. Er ist sehr gut, aber es gibt auch viele kommerzielle Application-Server, die Servlet- und JSP-Container integriert haben.
Zur ersten Frage: in der "Industrie" (oder soll ich eher schreiben, im professionellen Bereich?) ist JSP sehr stark verbreitet, da es vor allem Entwickler anspricht, die einen gut geplanten Entwicklungsprozess gewohnt sind. So ist zum Beispiel der Model-View-Controller-Ansatz sehr schön damit umzusetzen, wenn man Servlets und Taglibs hinzunimmt.

Wie sind diese Subprojekte zu verstehen, welche braucht man davon  -  und wofür braucht man sie (bitte: auf die englischsprachige Doku zu verlinken, bringt mir nix, weil ich die sehr wohl gelesen, aber bestimmt nicht richtig verstanden habe)?

Die Subprojekte haben nicht immer was mit Tomcat zu tun, sondern sind oft einfach während dessen Entwicklung entstanden und vielseitig einsetzbar.
Einige Beispiele:
Ant - der Beschreibugnstext trifft es schon ganz gut: "Apache Ant is a Java-based build tool. In theory, it is kind of like Make, but without Make's wrinkles."
JMeter - Ein Performance-Testtool
Log4J - Eine Logging-API (Wieso eigentlich _die_ API? Es ist doch _das_ Interface?)
Struts und Taglibs sind wiederum stark mit Tomcat verbunden.

Ich weiß, es ist nicht immer leicht, da den Überblick zu behalten. Aber Apache ist da noch besser als Sun; die machen mich mit ihren Kürzeln noch wahnsinnig! ;)

Grüße aus Berlin

Zurück aus Köln
VG Simon

[Christoph Schnauß]

hallo Simon,

Zur ersten Frage: in der "Industrie" (oder soll ich eher schreiben, im professionellen Bereich?) ist JSP sehr stark verbreitet, da es vor allem Entwickler anspricht, die einen gut geplanten Entwicklungsprozess gewohnt sind.

Das ist (unter anderem) das, was ich nicht verstehe. Ich bin ein großer Freund von "gut geplanten Entwicklungsprozessen", aber ich sehe noch nicht, welche Vorteile JSP da gegenüber anderen Techniken bietet.

Ant - der Beschreibugnstext trifft es schon ganz gut: "Apache Ant is a Java-based build tool. In theory, it is kind of like Make, but without Make's wrinkles."

Eben: "in theory it is ..."  -  wie setze ich das jetzt in irgendeine Praxis um?

Ich weiß, es ist nicht immer leicht, da den Überblick zu behalten

Ich kann bedauerlicherweise keinen Überblick "behalten", weil ich  - was Tomcat angeht (und _nicht_ den Apache-HTTP-Server)  -  noch nie  irgendwelchen Überblick hatte :-(

Grüße aus Berlin

Christoph S.

[Martin Jung]

Hi Christoph,

Das ist (unter anderem) das, was ich nicht verstehe. Ich bin ein großer Freund von "gut geplanten Entwicklungsprozessen", aber ich sehe noch nicht, welche Vorteile JSP da gegenüber anderen Techniken bietet.

Was wären die 'anderen Techniken'? Alle prinzipiell verwendbaren? Alle vergleichbaren? Alle für ein konkretes Projekt theoretisch verwendbaren? Solche, die sich bei einem konkreten Projekt anbieten, weil sie sich 'relativ einfach' in eine existierende Server-/IT-Infrastruktur intergieren lassen ? etc.
Solche Vergleiche abstrakt anzustellen, ist schwierig und wahrscheinlich wenig sinnvoll, aber dennoch zwei der solchen (unter Berücksichtigung, dass ich die 'anderen' vergleichbaren Techniken kaum kenne bzw. nicht auf dem neuesten Stand evtl. vorhandener Erweiterungen bin. Daher: Korrekturen sind höchst willkommen):
JSP vs. ASP: JSP funktioniert auf allen Java-Plattformen, ASP nur auf MS-Plattformen
JSP vs. PHP: Schenken sich funktional im Prinzip nichts (habe hier allerdings ein paarmal von 'schweren' Sicherheitslücken in bestimmten PHPP-Versionen gelesen)

Also:

• Soll eine Web-Applikation from Scratch entwickelt werden und es gibt kundenseitig keinerlei technische Vorgaben und 'wir' bekommen für eine PHP-basierte Lösung den Zuschlag, dann machen wir es mit PHP.
• Soll eine Web-Applikation from Scratch entwickelt werden und es gibt kundenseitig keinerlei technische Vorgaben, 'wir' können 'aber nur' Java und bekommen für eine Java-basierte Lösung dennoch den Zuschlag, dann machen wir es mit Java/JSP.
• Soll eine Java-basierte Enterprise-Applikation zu einer Web-Applikation erweitert werden, dann verwendet man sinnvollerweise JSP.
  Und so weiter und so fort...

Nochmal zu JSPs: Eine konsequente Trennung von Entwicklung und 'Webdesign' ist durch Vewendung von Taglibs (JSP-Tags) möglich. Das bedeutet, 'Webdesigner' können auf Präsentationselemente, hinter welchen sich komplexeste Logik verbergen kann, einfach durch XML-Syntax zurückgreifen. Aus Designersicht würde sich zur HTML-Referenz dann eine Taglib-Referenz gesellen.
Beispiel:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
<%@ taglib uri="customer-taglib.tld" prefix="cjsp" %>
<TITLE><cjsp:name /></TITLE>
<LINK REL=STYLESHEET
HREF="JSP-Styles.css"
TYPE="text/css">
</HEAD>
<BODY>
<H1><cjsp:fullname /></H1>
<cjsp:orders />
</BODY>
</HTML>

Diese Beispiel-Code könnte bewirken, dass alle Auftragsdaten eines bestimmten Kunden in der resultierenden HTML-Seite dargestellt werden. Welche Logik dazu notwendig ist (Datenbankzugriffe, Securitiy etc), ist für den 'Designer' irrelevant.

Ant - der Beschreibugnstext trifft es schon ganz gut: "Apache Ant is a Java-based build tool. In theory, it is kind of like Make, but without Make's wrinkles."
Eben: "in theory it is ..."  -  wie setze ich das jetzt in irgendeine Praxis um?

Indem Du in der Dokumentation nachliest ('Running Ant')?

Kurz zum Prinzip: Ant führt Tasks durch, die in einem XML-File ('build-file') als 'targets' definiert werden. Diese 'targets' können mit Hilfe des Attributes 'depends' miteinander verkettet werden, so dass man faktisch Ant auch als einen Batch-Interpreter auffassen kann.

Beispiel 'Kompilieren/Testen einer Applikation:
Logische Schritte könnten sein:
1. Vorbereiten des Dateisystems -> Erstellen eines Build-Verzeichnisses, evtl. mit Unterverzeicchnissen (wenn schon existent, dieses erst löschen) = target 'prepare'

<target name="prepare">
    <mkdir dir="${project.build.dir}*******" />
</target>

2. Kompilieren aller Java-Sourcen in build/classes (instanziiere dazu eine weitere VM, aber breche bei einem Fehler _nicht_ ab) = target 'compile'

<target name="compile" depends="prepare">
    <javac srcdir="${project.src.dir}" destdir="${project.build.dir}/classes" debug="off" failonerror="false">
        <pathelement path="${java.class.path}"/>
        <pathelement path="${Pfad zu weiteren notwendigen classes/jars}"/>
    </javac>
</target>

3. Kopiere alle Resourcen, die für die Unit-Tests benötigt werden, in ein entsprechendes Unterverzeichnis von build (und setze, wenn notwendig, den CLASSPATH entsprechend) = target 'test.prepare'

<target name="test.prepare" depends="compile">
    <copy todir="${project.build.dir}/resrc">
        <fileset dir="${project.resrc.dir}">
            <exclude name="irgendeinUnterverzeichnis/irgendeinDateiname.*" /><!-- aber kopiere keine Datei dieses Namens unabhängig der Extension, die in irgendeinUnterverzeichnis liegt -->
            <exclude name="**/*.doc" /><!-- und kopiere überhaupt keine Word-Dokumente -->
        </fileset>
    </copy>
</target>

4. Lasse die Tests laufen = target 'test.run'

<target name="test.run" depends="test.prepare">
    <java classname="de.mein-package.TestRunner" fork="true">
        <classpath>
            <pathelement path="${java.class.path}"/>
            <pathelement path="${project.build.dir}/classes"/>
            <pathelement path="${Pfad zu weiteren notwendigen classes/jars}"/>
        </classpath>
    </java>
</target>

5. Kopiere alle JSPs der Webapplikation in ein entsprechendes Unterverzeichnis von build  = target 'jsp.prepare'
weitere Beispiele erspare ich mir nun....

6. Prüfe. ob die JSPs syntaktisch korrekt sind. Dazu 'kompiliere' die JSPs in Java-Servlets (Jasper-Compiler) und diese anschließend in Bytecode = target 'jsp.compile'

In den Build-Files können Variablen definiert werden ('property'), die wiederum andere refenzieren können (expansion). Im Idealfalle (dem man eigentlich recht schnell nahe kommt) können die Target-Definitionen so allgemein halten kann, dass man sie für fast jedes Projekt vewenden kann. Man muss nur jeweils die 'properties' anpassen (Pfade der Sourcen, Resourcen, Build-Verzeichnisse etc.). Selbst diese muss man im Build-File nicht unbedingt anpassen, da die Werte auch aus Umgebungsvariablen ausgelesen werden können, und die projektspezifische Anpassung dadurch in eine userconfig.bat oder userconfig.sh verlagert werden kann, was m. E. noch einfacher/übersichtlicher ist.

Properties******* (müssen _vor_ den Targets deklariert werden!):

<property name="project.home"        value="${env.PROJECT_HOME}" /> <!-- aus Umgebungsvariable lesen -->
  <property name="project.build.dir"   value="${project.home}/build" />
  <property name="project.src.dir"     value="${project.home}/src" />
  <property name="project.resrc.dir"   value="${project.home}/resrc" />

ein Aufruf 'build test.run' in der Konsole führt somit zur seriellen Abarbeitung der Schritte 1-4.

Ich weiß, es ist nicht immer leicht, da den Überblick zu behalten
Ich kann bedauerlicherweise keinen Überblick "behalten", weil ich  - was Tomcat angeht (und _nicht_ den Apache-HTTP-Server)  -  noch nie  irgendwelchen Überblick hatte :-(

Nun ja, wie Simon schon sagte, Tomcat ist die Referenzimplentierung bestimmter APIs (ein Servlet-Container, der JSP-Technologie untersützt). Tomcat ist auch ein Standalone-Webserver, kann aber genauso zusammen mit Apache betrieben werden (Verbindung über HttpConnectoren, siehe TOMCAT_HOME/conf/server.xml). Was _genau_ ist Dir denn unklar?

Viele Grüße,
Martin Jung