JSP = Servlet? Was sind Servlet überhaupt?

Da ich in letzter Zeit, vor allem hier, soviel positives über Java Servlets gehört habe und Java selbst auch seit ein paar Jahre mache (aber noch nie etwas mit Servlets) wollt ich diese auch mal ausprobieren.
Aber die erste Hürde: Was sind Servlets überhaupt?
Ich hab bisher soweit verstanden dass ich einen Webserver brauche, der diese Ausführen kann (Tomcat hab ich mir mal runtergeladen).
Aber sind Servlets jetzt komplette Java Programme oder einfach nur HTML Seiten mit bissle Java ähnlicher Syntax drin (JSP)?
Das einzige Beispiel in nem Buch wo ich auf die schnelle fand (Java ist auch nur eine Insel), hatte einfach eine Klasse von GenericServlet abgeleitet. Sind alle Servlets von der Klasse abgeleitet oder gibt es da verschiedene?
Ich weiß, viele Fragen. Aber mein Handbuch der Java Programmierung hat das Thema überhaupt nicht, Java ist auch nur eine Insel schneidet das Thema nur Bruchstückhaft an...
Könnt Ihr mir ein Buch empfehlen, dass die komplette Thematik von Java Servlets behandelt ohne groß auf die Grundlagen von Java selbst einzugehen?

de.wikipedia.org/wiki/Servlet
Vielleicht einfach mal googlen ?

Aber die erste Hürde: Was sind Servlets überhaupt?

Also ich würd Servlet als Controller für die Anfragen an den Server bezeichnen. Du hängst ja ein Servlet mittels der web.xml in irgendein Pfad ein und auf diesen nimmt der dann die Requests entgegen und kann sie entweder auf verschiedene Ebenen verteilen oder er schickt direkt die Rückmeldung via. dem PrintWriter von der HttpServletResponse zurück. (bissl schwer in kurzen Ansätzen zu erklären).
Geläufige Funktionen, die man überschreibt sind entweder DoGet, DoPost oder DoRequest. Die Namen kannste dir ja ausm PHP herleiten, was die verarbeiten

Aber sind Servlets jetzt komplette Java Programme oder einfach nur HTML Seiten mit bissle Java ähnlicher Syntax drin (JSP)?
Ich würds halt als einen Controller in einem großen Programm, deiner Internetanwendung, beschreiben. JSP ist wieder ein anderes Ding. JSP gehört eher zur View-Schicht deiner Applikation, wo du wirklich HTML mit JSP mischen kannst. Du kannst zwar mittels JSP alles auch so ohne Controller bewerkstelligen, aber bei größeren Projekten wirds dann ein wenig unübersichtlich.
Du nimmst sozusagen das Request über nen Servlet an und verarbeitest die Daten in der Controller-Schicht. Packst die Daten zusammen und leitest das ganze an die View-Schicht, in dem Fall deine JSP-Datei, weiter. Diese stellt die Daten formschön dar.

Das einzige Beispiel in nem Buch wo ich auf die schnelle fand (Java ist auch nur eine Insel), hatte einfach eine Klasse von GenericServlet abgeleitet. Sind alle Servlets von der Klasse abgeleitet oder gibt es da verschiedene?
Ja im Gesamten sind alle von der Klasse GenericServlet abgeleitet. Normalerweise baut man ein Servlet aber auf der Klasse HttpServlet auf, also leitet von der Klasse ab (zumindest mach ich das immer so ) Da werden dann mehrere Funktionen zur Verfügung gestellt, die du durchs ableiten von GenericServlet nicht hast. HttpServlet biete zum Beispiel die ganzen DoXXX-Funktionen an, die GenericServlet nicht anbietet.

Könnt Ihr mir ein Buch empfehlen, dass die komplette Thematik von Java Servlets behandelt ohne groß auf die Grundlagen von Java selbst einzugehen?
Das J2EE Premium-Codebook
Wobei das sicher Geschmackssache ist (ich sehe gerade, dass es schon billig ist ^^ hab letztens im Buchladen das Ding für 100 € gesehen - kann aber auch ne andere Ausgabe sein).
Also wenn du Bücher suchst, dann such einfach nach J2EE und du wirst überschüttet mit Büchern
Ich hoffe ich konnt ein wenig helfen und ich hoffe ich hab nichts falsches erzählt ^^
edit: ach nee ich hab das Buch hier im Handel gesehen. Schade zu früh gefreut

Also die Definition bei Wikipedia finde ich nicht ganz so toll. Deshalb mal ein eigener Erklärungsansatz:
Servlets sind einfache Java Klassen, die das Interface javax.servlet.Servlet implementieren. Oftmals leitet man Sie aber von einer spezifischeren Klasse ab.

public class MyServlet extends javax.servlet.http.HttpServlet implements javax.servlet.Servlet 

Solch ein Servlet lebt innerhalb eines Containers, wie Tomcat, und nimmt Requests entgegen. Diese Request werden durch das Servlet verarbeitet und ein Response generiert, der an den Client zurück geschickt wird. Also eigentlich ähnlich wie ein PHP-Skript, lässt man den Mix auf PHP und HTML weg.
JSPs sind eine Erweiterung von Servlets. In JSPs kann HTML und JavaCode gemischt werden und es stehen spezielle Tags zur Verfügung. Das mutet schon mehr wie der bekannte PHP + HTML Mix an. Auch die JSPs werden mit einem Server, wie Tomcat, ausgeliefert. Intern ist es sogar so, dass die JSPs zu Servlets "kompiliert" werden.
Alles was Du zu dem Thema brauchst, findest Du im Dokumentationsarchiv bei Sun.
Aber überleg Dir gut, ob Du damit arbeiten möchtest. Ich sitze gerade an einer Semesterarbeit auf Basis von JEE5 und JSP. Und wenn ich den Aufwand mit anderen mir bekannten Technologien für webbasierte Anwendungen vergleiche, gestaltet es sich um ein vielfaches Aufwendiger. Darüber hinaus scheint da einiges an Sun vorbei gegangen zu sein. In dem Projekt wollte ich gestern Abend einen Anwendungsfall fertig stellen, der einen File Upload benötigte. Kein Thema denkt man sich, bis man feststellt, dass die Servlet API das gar nicht unterstützt. Und so lässt sich die Liste unendlich weiter führen. Vermutlich stelle ich meine Projektdoku nach der Abgabe am Freitag online. Dann kannst Du ja mal einen Blick rein werfen.

Danke schon mal für die Antworten
Das was Wikipedia dazu schreibt ist wirklich nicht sehr sprechend dazu (hatte es mir aber vorher auch durchgelesen).
Was mich halt sehr abgeschreckt hat, waren die JSP Sachen. Da ich gemischte Sachen von HTML und Java/PHP sehr unschön finde und damit auch ungern arbeiten will (bei mir wird direkt in den Klassen die HTML Struktur generiert, das View übernimmt dabei rein das CSS, was ich sehr viel angenehmer finde).
Java bzw. Compilierte Sprachen finde ich allein schon vom Entwicklungszyklus langsamer, da man für jeden Test die Applikation compilieren muss (in der Firma dauert das immer um die 5 min, wenn man sich noch nicht so sehr mit der Thematik auskennt und viel testen muss, dauert das recht lange).
Für mich kristallisieren sich bisher folgende Vorteile der beiden Sprachen:
Servlet:
- Gute Performance durch halb compiliertem Bytecode
- "Sichere" Programmierung durch Typisierung
PHP:
- Schneller Entwicklungszyklus wegen Skripteigenschaften
- Breite Unterstützung auf Webspace und Webservern
Ich denke ich werde mir Servlets genauer anschauen, aber mein Projekt auch weiterhin unter PHP führen, da ich erstens zu großen Teilen schon fertig bin und zweitens außer der Performance noch keinen Nutzen sehe, außer dass ich einen neuen Hoster suchen müsste.
Das Projekt würde ich mir dann sehr gerne anschauen Agmemon, kannst es ja per PN dann schicken bzw. posten wenn fertig bist.
Das Buch werde ich mal bei Amazon suchen und anschauen, da ich Bücher zu diesem Thema von meiner Firma bezahlt bekomme, werde ich es mir sicherlich auch holen. ^^

> Java bzw. Compilierte Sprachen finde ich allein schon vom Entwicklungszyklus langsamer
Kann ich so nicht bestätigen.
Unter PHP habe ich zum Teil viel längerere Debugging-Sessions, da ich alle Funktionen abfahren muss um auch jeden Quellcodeteil auf Tippfehler und ähnlichem zu überprüfen.
Nicht umsonst gibt es den Spruch: 'It compiles, let's ship it'. Mit genügend Übung und Selbstdisziplin nutze ich den Compiler als einzige Überprüfung ob etwas funktioniert. Solang man keine riesigen Abläufe ändern, sondern nur Details ist dies ein gangbarer Weg.
Ich persönlich programmiere unter ASP.Net und gerade der Compiler spart mir verdammt viel Zeit, da ich schon weiß, dass das Geschriebene syntaktisch korrekt ist. Und ein Recompile meines Spieles (jungfrauenspiel.de) braucht mit 22 Unterprojekten und knapp 500 Dateien etwa 30 Sekunden (AMD X2 4000+).
Java und C# kompilieren wesentlich schneller als C++-Programme. Vielleicht nutzt ihr in eurer Firma C++.
Ansonsten empfehle ich dir die Nutzung von JSP (auch wenn ich kein Java-Fan bin, aber das tut hier eigentlich nichts zur Sache ;-) ). Zumindest eine kompilierte Sprache sollte man sich mal angetan haben....

Original von TheUndeadable
Ich persönlich programmiere unter ASP.Net und gerade der Compiler spart mir verdammt viel Zeit, da ich schon weiß, dass das Geschriebene syntaktisch korrekt ist. Und ein Recompile meines Spieles (jungfrauenspiel.de) braucht mit 22 Unterprojekten und knapp 500 Dateien etwa 30 Sekunden (AMD X2 4000+).

Mein Eclipse zeigt mit im PHP alle Syntaxfehler an und angeschaltetes Error Reporting zeigt Tippfehler in Variablen an, da sehe ich eigentlich kein Problem drin.

Original von TheUndeadable

Java und C# kompilieren wesentlich schneller als C++-Programme. Vielleicht nutzt ihr in eurer Firma C++.
Stimmt, in der Firma nutzen wir C++. Haben ca 50 Unterprojekte und unser Hauptmodul hat ca. 1200 Dateien. Beim mir (naja, man merkt dass ich den ältesten Rechner hab ^^) dauert das Compilieren um die 1-15 Minuten, je nachdem ob ich nur ne .cpp oder ne etwas häufig verwendete .h/.hpp Datei ändere. ^^

Original von TheUndeadable

Ansonsten empfehle ich dir die Nutzung von JSP (auch wenn ich kein Java-Fan bin, aber das tut hier eigentlich nichts zur Sache ;-) ). Zumindest eine kompilierte Sprache sollte man sich mal angetan haben....
Man sollte mindestens eine compilierte und eine Skriptsprache mal gemacht haben, allein schon um den Unterschied gut zu kennen.
Ich persönlich hab bisher Java und C++ intensiv gemacht auf der compilierten Seite, sowie Lua und PHP auf der Skriptseite.
Und gerade weil ich Java intensiver gemacht hab (3 Jahre während der Abiturzeit in der Schule und Privat und nun in der Berufsschule seit 2 Jahren), jedoch bisher nichts mit Servlets, interessiert mich das Thema ja sehr.
Ich glaub ich bin in Sachen Java immer noch von unsren Applets in der 11. Klasse geprägt, wir haben es damals zusammen mit dem Lehrer nicht geschafft einen farbigen Kreis ruckelfrei zu bewegen... ich glaub das hat meine Ansicht auf Java für lange Zeit versaut gehabt. ^^

Original von DrakeL
Was mich halt sehr abgeschreckt hat, waren die JSP Sachen. Da ich gemischte Sachen von HTML und Java/PHP sehr unschön finde und damit auch ungern arbeiten will (bei mir wird direkt in den Klassen die HTML Struktur generiert, das View übernimmt dabei rein das CSS, was ich sehr viel angenehmer finde).

Wenn das so wäre, würde es sicher nervig sein, aber es ist nicht (unbedingt) so. JSPs sind eine View-Abstraktion, die Leuten, die eher aus der Webentwicklung kommen den Einstieg in JEE erleichtern sollen. Einsetzen MUSS man sie nicht - und wenn man knallhart Performance haben will, sollte man noch nicht mal. JSPs werden zu Servlets (noch einmal zusätzlich) kompiliert, was mit der in jedem automatisierten komplexen Prozess zu findenden Ineffizienz verbunden ist. View-Generierung kann man auch sauber in eigene (HTTP-)Servlets setzen und dann ist man von dem Look'n'Feel von PHP nicht so weit weg.

Original von DrakeL

Java bzw. Compilierte Sprachen finde ich allein schon vom Entwicklungszyklus langsamer, da man für jeden Test die Applikation compilieren muss (in der Firma dauert das immer um die 5 min, wenn man sich noch nicht so sehr mit der Thematik auskennt und viel testen muss, dauert das recht lange).
Kann ich auch nicht nachvollziehen. Lokal ist mein Entwicklungstomcat mit relativ komplexer (Annwendungs-)Initialisierungsprozedur in weniger als einer Minute automatisch von Netbeans mit einem neuen Kompilat versorgt.

Original von Teonas
Kann ich auch nicht nachvollziehen. Lokal ist mein Entwicklungstomcat mit relativ komplexer (Annwendungs-)Initialisierungsprozedur in weniger als einer Minute automatisch von Netbeans mit einem neuen Kompilat versorgt.

Dann ist Java in der Hinsicht wohl angenehmer
Ich werde es heut Abend dann einfach mal ausprobieren. Was mich bisher noch etwas irritiert, ist die Verzeichnisstruktur und die Einstellungen am Tomcat um auf Servlets zuzugreifen. Das hab ich noch nicht ganz verstanden, aber wird sicher beim ausprobieren klarer.

Vielleicht noch was aus der Tipps-und-Tricks-Ecke:
Das Deaktivieren der Zip-Komprimierung bei der Erstellung der .war (bei Netbeans bspw. ist die per Default an) bringt weitere Geschwindigkeitsvorteile beim lokalen Testen. Wenn man die .war remote installieren will, kann man die Größenvorteile dann wieder nutzen.

Die Zeit zum Compilieren, oder in dem Fall spricht mal wohl besser vom Deployment, geht eigentlich. Mein Projekt braucht auch ca. eine Minute für Web-Schicht und EJB-Schicht. Aber nervig ist es trotzdem, wenn man noch nicht so vertraut mit der Technik ist (Deploy, Test, Deploy, Test, usw.).
Was mit bei den JSPs noch aufgefallen ist: Trotz Compiler-Sprache kann das Debugging sehr aufwendig werden. In meinem Projekt nutze ich eine ganze Reihe von Entwurfsmustern (FrontController, ServiceLocator, CommandPattern, Composite Views und View Helper in Form von JSTL Tags). Die JSPs werden dadurch erst zur Laufzeit bei jedem Request zusammen gesetzt. Wenn es durch irgend einen Fehler nun dazu kommt, dass eine Exception geworfen wird, passiert es häufiger, das im Stack-Trace der Kommentar erscheint, dass der Ort der Auslösung unbekannt ist, da die JSP ja physikalisch nicht existiert.
Und ohne Java jetzt madig machen zu wollen, aber so schnell ist meine Anwendung zumindest nicht. Aber vielleicht liegt das aber auch an der EJB Schicht.

Original von Agmemon
Und ohne Java jetzt madig machen zu wollen, aber so schnell ist meine Anwendung zumindest nicht. Aber vielleicht liegt das aber auch an der EJB Schicht.

Oh ja - schon JSP kostet Perfomance, EJB oder JSF (Java Server Faces) bzw. ein weiteres mächtiges Framework drauf ist meist des Guten für den Hausgebrauch zuviel.

Ich denke schon, dass es einen Unterschied macht, vor allem wenn man für PHP keinerlei Cachesysteme (Accelerator) oder ähnliches benutzt.
Aber da ich auf jeden Fall kein Massenspiel machen will, sondern die Benutzerzahl so auf die 100 begrenze am Anfang, sollte das kein Problem darstellen (hoffe ich zumindest, hab damit ja noch keine Erfahrungen gemacht ^^).
Wenn dann will ich vorerst eh nur in die Servlets reinschauen, einfach weil ich es mal testen will. Und den größeren Vorteil sehe ich nicht in der Performance, sondern eher in der Typensicherheit, weil die bringt mit Sicherheit auch etwas mehr Stabilität in die Anwendung.

Direkt mit Servlets arbeiten sollte man auch nur machen, wenn man sich wirklich mit all den daraus resultierenden Arbeiten beschäfigen will, die tausende von Entwicklern schon Millionen mal vorher gemacht haben. Was ich sagen will: Wenn ich schon Java verwende, dann verwende ich ein MVC-Framework wie Spring MVC oder Struts (nur 2 Beispiele, die Auswahl ist recht groß). Ob das Performance-technisch sinnvoll ist, darüber lässt sich streiten. Aber es erleichtert die Entwicklung ungemein und bringt vorallem eine sinnvolle Struktur ins Projekt.
Was Testen und deployen betrifft: Die meisten Tests sollten zunächst sowieso als Unit-Tests funktionieren und ein Starten des Servers überhaupt nicht erfordern. Wenn man dann doch mal das Programm selbst anwerfen muss, dann hilft einem Eclipse mit entsprechenden Plugins unter die Arme. Die Eclipse Web Tools Platform erlaubt es "von Haus aus", Tomcat direkt aus der IDE zu starten und zu steuern. Ändere ich etwas am Code startet es automatisch den Server neu und ich kanns mir nach wenigen Sekunden anschauen, ohne selbst etwas tun zu müssen. Handelt es sich beim geänderten nur um JSP-Dateien, dann gehts sogar ohne kompletten Neustart. Man kann also am Layout arbeiten wie man es von PHP oder ähnlichen Skiptsprachen gewöhnt ist.
Zusatz: Das deployen auf dem Server löse ich btw über Ant. Diese checkt das gesamte Projekt aus CVS aus, kompiliert es und baut die .war zusammen. Alles unter 20 Sekunden und ohne nervige Uploads. Die Gameserver und der CVS-Server stehen im selben Serverzentrum. Daher geht das fix

Zum Thema Performance von Multi-Layer-Architekturen mit Java liest dieser (allerdings nicht gerade taufrische) Artikel ganz unterhaltsam: rubis.objectweb.org/download/Middleware-2003.pdf

Servlets bieten nicht zufällig die Möglichkeit ein paar dieser Sachen:
- Objekte von mehreren Requests benutzen und über den Request hinaus instanziert aufbewaren
- ConJob ähnliche Funktionen, daher Objekte/Methoden in bestimmten Zeitintervallen ausführen lassen
Vom letzterem hab ich irgendwas gelesen, bin mir aber nicht mehr ganz sicher, das andre wär für mich schön, da es bei mir ein paar Teile gibt, die immer geladen werden müssen und sich aber nie/selten verändern (Einstellungen, Connectionpooling, Sprachdateien).

Original von DrakeL
- Objekte von mehreren Requests benutzen und über den Request hinaus instanziert aufbewaren

Nein, das was du meinst sind JavaBeans
Servlets sind ausschließlich zur Steuerung des Verhaltens. Zum Sichern und Weiterreichen (quasi als Datencontainer) nimmt man Beans.
Und dort ist das ohne weiteres möglich in folgenden Werten: Session, Request, Appliaction. Die Lebenszeit erkennst du jetzt ja sicher

Original von DrakeL

- ConJob ähnliche Funktionen, daher Objekte/Methoden in bestimmten Zeitintervallen ausführen lassen
Nein, Servlets nicht. Aber eine Webseite ist nichts anderes als ein Java-Programm ausgeführt in einem bestimmten Kontext. Dementsprechend ist natürlich alles möglich was mit Java möglich ist: also kannst du auch "CronJobs" implementieren.

Original von Samson
Nein, das was du meinst sind JavaBeans
Servlets sind ausschließlich zur Steuerung des Verhaltens. Zum Sichern und Weiterreichen (quasi als Datencontainer) nimmt man Beans.
Und dort ist das ohne weiteres möglich in folgenden Werten: Session, Request, Appliaction. Die Lebenszeit erkennst du jetzt ja sicher

Schon paar mal gehört, aber nicht wirklich mehr dazu nachgelesen bzw. verstanden. Aber mit einem dieser Beans lässt sich dann auch das CronJob Problem lösen, indem man Ihn in ner Endlosschleife laufen lässt und mit Sleep seinen Intervall bestimmt indem er ruht. Natürlich in nem eigenen Thread
Mmh, ich finde irgendwie immer mehr Argumente um auf Java zu wechseln. ^^

Original von Samson

Original von DrakeL
- Objekte von mehreren Requests benutzen und über den Request hinaus instanziert aufbewaren

Nein, das ......
ahhhhhhh nicht ganz:
siehe -> aschauf.landshut.org/fh/studienprojekt/vortrag_servlets/2.4.html

mmh, und was sagt mir die Seite? ServletContainer ist doch ein Servlet, oder?

Ein Servlet erbt ja von der Klasse HttpServlet. Und die HttpServlet hat eine (geerbte) Methode getServletContext(). Darin kannst du Objekte ablegen, die auch nach dem Request noch da sind.

Ok

Original von planetenkiller
Darin kannst du Objekte ablegen, die auch nach dem Request noch da sind.

Es gibt einen Kontext für die User-Session, einen für den Request an sich und einen für alle Requests.
Hab ich das richtig verstanden?

Im Regelfall gibt es bei Application-Server folgende Kontexte (zumindest bei ASP.Net):
- Request
- Session
- User
- Server
- Serverübergreifend (letzteres muss zum Teil manuell bewältigt werden)

Original von planetenkiller
ahhhhhhh nicht ganz:
siehe -> aschauf.landshut.org/fh/studienprojekt/vortrag_servlets/2.4.html

Ja, aber das nutzt man nur für Counter und kleinere Dinge. Daten die ich persistent haben will, stehen nicht in ner Servlet. Aber lässt du ne Servlet in nem Applicationkontext laufen, kannst du natürlich int counter; haben der auch bestehen bleibt.
Aber eine persistente Sicherung in der Servlet ist böse
Übrigens wird der ServletContext zum Holen von Beans & anderen Daten verwendet
Die Sicherung erfolgt nicht in der Servlet!

Original von DrakeL
Aber mit einem dieser Beans lässt sich dann auch das CronJob Problem lösen, indem man Ihn in ner Endlosschleife laufen lässt und mit Sleep seinen Intervall bestimmt indem er ruht. Natürlich in nem eigenen Thread
Mmh, ich finde irgendwie immer mehr Argumente um auf Java zu wechseln. ^^

Dies geht sicherlich auch. Aber für sowas gibts auch extra Klassen. Merke dir eins: Es gibt für fast jedes allgemeine Problem irgendeine Klasse in Java
Die Klasse, die ich mein, versteckt sich im java.util Paket und nennt sich Timer (welch Wunder ),die nach bestimmten Angaben eine Klasse mit abgeleiteter abstrakten Klasse TimerTask ausführt.
Sehr gut erklärt ists eigenltich unter www.dpunkt.de/java/Programmieren_mit_Java/Multithreading/17.html
Zumindest hat ich da verstanden, was die von mir wollten
Referenz: java.sun.com/j2se/1.4.2/docs/api/java/util/Timer.html

Hab mal etwas ausprobiert und mir die aktuelle Tomcat Version installiert, sowie das Eclipse für JEE Development. Hab dann ein neues Projekt gemacht (Web -> Dynamic Web Project) und eine Servlet Klasse in das Verzeichnis "Java Resources: src" erstellt.
Nach dem compilieren und ausführen bekomme ich vom Tomcat allerdings nur die Meldung, dass die aufzurufende Klasse nicht existiert... Was muss ich denn machen, damit ich überhaupt mal ein Servlet zum laufen bringen kann?
Des weiteren hab ich gelesen, dass ein Servlet, welches von HttpServlet abgeleitet ist Methoden wie "doGet()" und "doPost()" anbietet. Das sieht für mich aber dann auch so aus, dass es nicht möglich ist, beides miteinander zu verbinden, oder?
also die Sachen im HTML wie folgt zu verwenden:

...

Hier hätte ich dann gerne, dass ich den GET Parameter "page" und die POST Parameter des Formulars auswerten kann. Geht das mit einem Servlet dann überhaupt?
Wäre für mich schon recht wichtig, dass dies funktioniert, da so die Navigation einfach über die URL ablaufen kann und sämtliche Formulardaten über POST.

Des weiteren hab ich gelesen, dass ein Servlet, welches von HttpServlet abgeleitet ist Methoden wie "doGet()" und "doPost()" anbietet. Das sieht für mich aber dann auch so aus, dass es nicht möglich ist, beides miteinander zu verbinden, oder?

Das geht, mache einfach zb eine Methode
processRequest(HttpServletRequest request, HttpServletResponse response)
und dann rufe in doGet und doPost diese Methode auf
processRequest(request, response);

hätte ich dann gerne, dass ich den GET Parameter "page" und die POST Parameter des Formulars auswerten kann. Geht das mit einem Servlet dann überhaupt?

Get und Post Parameter können beide beim request objekt ( request.getParameter ) geholt werden. Bei einem Test, wo ich im Formular bei action einen Parameter definiert habe und im Formular ein Textfeld mit den gleichen namen, gab mir das request.getParameter das zurück was im Get stand, egal was ich ins Textfeld schrieb.
Kurz: Egal ob Post oder Get beides wird als Parameter gewertet und kann über request.getParameter geholt werden. Wenn ein gleicher Get und Post Parameter da ist, scheint der Get das Post zu überschreiben.
Beim Problem mit Eclipse weiss ich leider nichts, da ich mit Netbeans arbeite.
Hast du von Tomcat die exe oder das zip heruntergeladen? Ich musste das zip herunterladen damit Netbeans Tomcat starten und stoppen konnte und es allgemein richtig funktionierte.

Original von DrakeL
Des weiteren hab ich gelesen, dass ein Servlet, welches von HttpServlet abgeleitet ist Methoden wie "doGet()" und "doPost()" anbietet. Das sieht für mich aber dann auch so aus, dass es nicht möglich ist, beides miteinander zu verbinden, oder?

Na das macht doch aber Sinn
Warum hast du GET Parameter? Du willst von einer Klasse/Datei/Einheit also mehrere Funktionen zur Verfuegung haben. Standardmaessig wird aber davon ausgegangen (OOP und Wiederverwendbarkeit eben), dass jede Klasse/Datei/Einheit eine Funktion erfuellt und diese kann beliebig von spezialiserten Klassen uebernommen werden.
Ergo: fuer jede (logische) Aufgabe solltest du eine eigene Einheit haben. Wenn eine Klasse den Useraccount aendern kann und gleichzeitig das Kampfscript aufruft, bist du auf Abwegen.

Original von planetenkiller
Beim Problem mit Eclipse weiss ich leider nichts, da ich mit Netbeans arbeite.
Hast du von Tomcat die exe oder das zip heruntergeladen? Ich musste das zip herunterladen damit Netbeans Tomcat starten und stoppen konnte und es allgemein richtig funktionierte.

Hab Tomcat als .exe runtergeladen und installiert. In Eclipse geb ich dann das INstallationsverzeichnis von Tomcat an, sodass dieses Programme direkt über den Server ausführen kann. Bei einem Beispielcode ausm Buch wurde einfach die "doGet()" Methode überschrieben und die Seite aufgerufen, aber nichts passiert.
Das Projekt mit den ".class" Dateien ist im übrigen auch nicht in den Tomcat Verzeihcnissen zu finden. Sondern Eclipse erstellt diverse Tomcat Dateien im Verzeichnis des Projektes.

Original von Samson

Warum hast du GET Parameter? Du willst von einer Klasse/Datei/Einheit also mehrere Funktionen zur Verfuegung haben. Standardmaessig wird aber davon ausgegangen (OOP und Wiederverwendbarkeit eben), dass jede Klasse/Datei/Einheit eine Funktion erfuellt und diese kann beliebig von spezialiserten Klassen uebernommen werden.
Ergo: fuer jede (logische) Aufgabe solltest du eine eigene Einheit haben. Wenn eine Klasse den Useraccount aendern kann und gleichzeitig das Kampfscript aufruft, bist du auf Abwegen.
Ich will nur ein Servlet haben, die je nachdem, auf welcher Seite sich der Benutzer befindet, andere Klassen lädt. Daher es wird immer das gleiche Servlet aufgerufen, aber wenn der Benutzer auf "Startseite" klickt, wird z.B. von der Klasse Startseite ein Objekt erstellt und dessen Rückgabe für den Inhalt genommen.
Wenn auf der Startseite nun ein Login enthalten ist (Beispielhaft), brauch ich die Information, dass die Startseite geladen werden soll (in PHP immer index.php?page=startseite z.B.) und über das POST bekomm ich dann die Formulardaten für den Login.
Daher die Navigation über die Homepage erfolgt über die GET Parameter, alles andere über POST (a tags können nicht einfach POST Daten senden, sondern nur auf URLs verweisen, denen man halt GET Variablen mitgibt).

Original von DrakeL
Nach dem compilieren und ausführen bekomme ich vom Tomcat allerdings nur die Meldung, dass die aufzurufende Klasse nicht existiert... Was muss ich denn machen, damit ich überhaupt mal ein Servlet zum laufen bringen kann?

Meinst Du mit Ausführen den Aufruf des Servlets im Browser? Wenn dem so ist, hast Du denn eine Konfigurationsdatei, wo Deine Servlets konfiguriert sind? Ohne diese Datei "web.xml" geht meines Wissen nach nämlich gar nichts.

Original von DrakeL

Des weiteren hab ich gelesen, dass ein Servlet, welches von HttpServlet abgeleitet ist Methoden wie "doGet()" und "doPost()" anbietet. Das sieht für mich aber dann auch so aus, dass es nicht möglich ist, beides miteinander zu verbinden, oder?
Das ist ganz einfach: Du schreibst in deinem Servlet eine neue Methode und rufst diese aus den Methoden doGet() und doPost() auf:

protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {

doService(request, response);
}

protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
doService(request, response);
}

private void doService(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException{ //request bearbeiten }

Original von DrakeL
Wenn auf der Startseite nun ein Login enthalten ist (Beispielhaft), brauch ich die Information, dass die Startseite geladen werden soll (in PHP immer index.php?page=startseite z.B.) und über das POST bekomm ich dann die Formulardaten für den Login.

Das Stichwort hierzu heißt FrontController Pattern. In meinem Studienprojekt habe ich das in Kombination mit dem Command-Pattern umgesetzt. Über die web.xml wurden alle Aufrufe an das FrontController Servlet weitergereicht. Über die URI wurde dann in eine HashMap die Klasse zu dem Aufruf bestimmt. Diese Klassen hatten alle die Methode run(). Die Klasse wurde dann dynamisch instanziiert und die Methode aufgerufen. IN der Methode wurden dann alle Aufgaben ausgeführt und alle Daten für die Visualisierung gesammelt. Und das wurde das ganze an ein CompositeView weiter gegeben.

Original von Agmemon
Meinst Du mit Ausführen den Aufruf des Servlets im Browser? Wenn dem so ist, hast Du denn eine Konfigurationsdatei, wo Deine Servlets konfiguriert sind? Ohne diese Datei "web.xml" geht meines Wissen nach nämlich gar nichts.

Mit "Ausführen" mein ich das Compilieren und Ausführen über Eclipse. Dieses startet den Tomcat Server und ruft die URL auf für das Projekt. Ich schau mal in diese "web.xml" rein und füge dann den Pfad zu dem Servlet hinzu.

Original von DrakeL

Das ist ganz einfach: Du schreibst in deinem Servlet eine neue Methode und rufst diese aus den Methoden doGet() und doPost() auf...
Dann kann ich das Servlet auch einfach mit den GET Parametern erweitern?

...

Welche der beiden Methoden wird dann aufgerufen? Ich denke mal die "doPost()" Methode. Ich würde mir dann einfach alle Parameter holen und intern im Servlet als Memervariable zwischenspeichern und dann den Aufruf an die "doGet()" Methode weitergeben, dürfe das Sauberste sein.
Zumindest, wenn ich Unterscheiden kann, mit welcher Art der Parameter übergeben wurde. Kann ich mir denn mit einer Funktion alle GET bzw. alle POST Parameter zurückgeben lassen?

Original von DrakeL
Welche der beiden Methoden wird dann aufgerufen? Ich denke mal die "doPost()" Methode. Ich würde mir dann einfach alle Parameter holen und intern im Servlet als Memervariable zwischenspeichern und dann den Aufruf an die "doGet()" Methode weitergeben, dürfe das Sauberste sein.
Zumindest, wenn ich Unterscheiden kann, mit welcher Art der Parameter übergeben wurde. Kann ich mir denn mit einer Funktion alle GET bzw. alle POST Parameter zurückgeben lassen?

Kommt ein Request per HTTP GET wird doGet() aufgerufen, bei HTTP POST doPost(). Wenn es Dich nicht interessiert, wie die Daten übermittelt wurden, leitest Du einfach beide Aufrufe an eine dritte Methode weiter, die die Abarbeitung übernimmt. Zwischenspeichern in einer Membervariable ist unsinnig, gerade da Du ja eigentliche das FrontController-Pattern anwenden willst. Alle Daten sind im Request-Objekt gespeichert. Und das reichst du einfach immer weiter.
Das RequestObjekt verfügt auch über Methoden, um sich eine Liste aller Parameter (also aller Daten die als Parameter von der Seite kommen) oder Attribute (das sind die HTTP bezogenen Daten und Werte die du im Quelltext im Request speicherst) als Enumeration zu holen.

Original von DrakeL
Wenn auf der Startseite nun ein Login enthalten ist (Beispielhaft), brauch ich die Information, dass die Startseite geladen werden soll (in PHP immer index.php?page=startseite z.B.) und über das POST bekomm ich dann die Formulardaten für den Login.

Das ist aber etwas unelegant dann. In der web.xml richtest du einfach ein, dass alle Anfragen auf ein Servlet gehen (vgl. dem Controller von Agmemon). Anhand der URL (die eh immer auf dein Servlet gemappt wird), bestimmst du den Rest. Vorteil: automatisch schon suchmaschinen optimiert und nutzerfreundlich
Wird aber unter PHP - meines Wissens - genauso gehandhabt. Nur das hier dann der Apache per mod_rewrite das Ganze abarbeitet.

Kleiner Tipp noch DrakeL: Wenn Du mit Servlets und Co. arbeitest, vergiss einfach wie man was in PHP machen würde. Das gibt nur graue Haare.

Ich möchte durch das hinzufügen einer neuen Seite so wenig Aufwand wie möglich haben. Daher im Moment füge ich die PHP Klassen für die neuen Seiten hinzu (eine bzw. mehrere falls die Seite weitere Unterseiten besitzt) und erweitere das Array, welche meine Seitenstruktur enthält, woraus das Menü zusammen gestellt wird.
Wenn ich jetzt noch Einstellungen am Server machen muss, nur wegen einer neuen Seite, dann finde ich das krässlich. Vor allem, wenn ich mehrere Projekte haben und alle Einstellungen der Seiten in einer Datei am Server geändert werden müssen für die verschiedenen Projekte.
Die Lösung, die Ihr meint wäre ja, dass man "startseite.html" aufruft und dann auf das Servlet mappt und dem einfach Parameter mit gibt, oder? Das wäre ja in Ordnung, aber gibt es dann eine Möglichkeit, die Einstellungsdatei mit dem Mapping für den Server in das Projektverzeichnis zu legen, statt alles in einer Datei am Server zu haben?
PS: Falls gerade jemand erfahreneres Zeit/Lust hat, kann er mich auch ma im ICQ anschreiben, ich würde sehr gerne bissle mit Servlets spielen, aber ich bekomm ja immer noch nicht das Beispiel aus dem Buch zum Laufen, wenn ich das mache, was im Buch steht. ^^

Original von Agmemon
Das ist ganz einfach: Du schreibst in deinem Servlet eine neue Methode und rufst diese aus den Methoden doGet() und doPost() auf

Es gänge doch noch einfacher, indem man einfach die Funktion service überschreibt. Da gehen alle möglichen Requests ein und werden nur in der Klasse HttpServlet an die weiteren Funktionen verteilt. Wenn man die nun überschreibt kann man das selber handhaben.

Die Lösung, die Ihr meint wäre ja, dass man "startseite.html" aufruft und dann auf das Servlet mappt und dem einfach Parameter mit gibt, oder? Das wäre ja in Ordnung, aber gibt es dann eine Möglichkeit, die Einstellungsdatei mit dem Mapping für den Server in das Projektverzeichnis zu legen, statt alles in einer Datei am Server zu haben?
Ja es gibt dann schon diverse Unterschiede zu php. Also Entweder du machst es so wie Agmemon es meinte, indem du ein FrontController hast und dieser dann deine Seitenaufrufe verteilt, so dass du nichts mehr an der web.xml vornehmen musst, oder du nutzt das gegebene deines Webservers.
Sagen wir du hast deine Webapplikation auf / liegen. Das Servlet, was du noch dazu hast soll unter /Servlet liegen. Dann werden alle Seite, die auf dem Pfad /Servlet und auch darunter liegen auf dieses Servlet gemappt. Nun hast du aber noch deine JSP- und HTML-Dateien, die du nur zur Anzeige nutzen willst. Diese kannst du auch in den Ordner / reinhauen und meines Wissens nach erkennt Tomcat diese Sachen sofort und du brauchst es nicht explizit in der web.xml anlegen.
Diese web.xml liegt normalerweise im Unterorder WEB-INF, wo auch deine benötigten Klassen und jar dateien liegen (natürlich in weiteren Ordnern). Wenn du nun eine neue Datei hast, die als Servlet arbeiten soll, dass musst du alles reinkopieren und bei Tomcat deine Applikation neu deployen (geht per /manager als url). Meines wissens nach unterstützt Tomcat kein Hot-Deployment, aber ich kann mich auch irren.
Wenn du aber nur paar JSP-Dateien ändern willst, die ja im root-Ordner deiner Webapplikation liegt, dann dürfte das auch sofort gehen. Aber ist schon ein wenig her, wo ich Tomcat als Webserver genutzt hatte.
Aber wie Agmemon shcon sagte. Meist ist es nicht so wie in php, wo man einfach mal schnell was entwickelt und gleich testen kann. Man muss schon immer die Webapplikation neu deployen, damit der Server die Änderung merkt.
Du könntest nun zum Beispiel eine XML-Datei erstellen, welche deine Seitenstruktur enthalten soll. So kann der Controller für deine Anfrage auch die richtigen Ziele für die Anfragen rausbekommen und du bekommst dein Menu auch gut ausgelesen.

Wenn ich jetzt noch Einstellungen am Server machen muss, nur wegen einer neuen Seite, dann finde ich das krässlich. Vor allem, wenn ich mehrere Projekte haben und alle Einstellungen der Seiten in einer Datei am Server geändert werden müssen für die verschiedenen Projekte.
Dank der web.xml brauchst du dir um die anderen Projekte keine Gedanken machen, da diese ja damit nicht betroffen sind und du nur diese Applikation neu deployen musst (oder du startest halt den Server immer neu).

Also erstmal musst Du aufhören in Dateien zu denken. Du registrierst in der web.xml, die übrigens Projekt und nicht Server bezogen ist. Und dann trägst Du dort das Mapping ein:

OnlineShopServlet
/OnlineShopServlet/*

Damit erreichst Du, dass alle Zugriffe auf server/projekt/OnlineShopServlet an das Servlet weiter gereicht werden. Und alles was als * im Pattern steht, wird einfach an das Servlet übergeben. Anstatt das du in PHP irgendwie index.php?command=blabla machst, rufst Du die Seite über OnlineShopServlet/blabla auf.
Im Servlet selbst bestimmst Du dann, was hinter OnlineShopServlet/ kam und hast Dein command-Parameter.
Noch was allgemeines zum Thema Konfigurationsdateien: damit musst Du in dem Bereich leben. Wenn Du erstmal die anfängst die Standard Bibliotheken zu nutzen, kommen noch eine ganze Reihe von weiteren Konfigurationsdateien hinzu, die dann auch immer angepasst werden müssen. Da ist die web.xml noch genügsam.

Hi, ihr kennt euch ja was aus, wie ich sehe
Meine Frage zielt auf Effizienz, Performance und auch ein bisschen Eleganz (also, Strukturierung und Co). Ist es gut, wenn man alle Aufgaben eines Requests und Responses (zum Beispiel Auflistung, Bearbeitung eines Elements (Tabellen in Datenbank)) in einem Servlet macht, also inkl. der Ausgabe (hier XSLT)? Oder sollte man nur Daten im Servlet bearbeiten und erstellen, die Ausgabe aber in einem JSP erledigen? Ich meine, das Stichwort dazu ist Dispatcher.
Ich habe ein kleines Projekt (mein erstes), und derzeit habe ich es so gelöst, das am Ende der doXXX Methoden nur ein "finish" steht, was Ausgabe, Transformation & Co erledigt.

Dispatcher und FrontController sind weitgehend äquivalente Begriffe. Ich finde diesen Ansatz sehr elegant. Die klassichen Dispatcher/FrontController enden aber meistens in riesigen if/else if Konstrukten, was nicht sehr schön ist. Daher habe ich den Ansatz gewählt, jede Aktion, die vom Benutzer ausgeführt werden kann, in einer Command Klasse zu kapseln. Im vorliegendem Fall hatte ich also für die BücherVerwaltung die Klassen BuchShow, BuchEdit, BuchDelete, BuchSave, BuchUpdate, usw.
Dieser Ansatz resultiert zwar in eine recht hohen Anzahl von Klassen, aber man hat eine saubere Trennung, kann leicht erweitern und modifizieren.
Über die URI wurde dann bestimmt, welche Kommando ausgeführt werden soll und die Klasse entsprechend dynamisch instanziiert.

String remoteMethod = requestURI.substring(requestURI.lastIndexOf('/') + 1);

String command = this.getCommandClass(remoteMethod);
Class c = Class.forName(command);
Command o = (Command)c.newInstance();
o.run(request, response, con);
Die Ausgabe haben dann JSPs übernommen, die von den Command Klassen aufgerufen wurden. Dabei kam das CompositeView Pattern zum Einsatz. Alle Anfragen sind also an eine spezielle JSP gegangen, die sich die notwendigen Blöcke zusammen gesucht hat.
Ich habe mal die Request Ablauf aus der Projektdoku angehängt.

Original von knalli
Hi, ihr kennt euch ja was aus, wie ich sehe
Meine Frage zielt auf Effizienz, Performance und auch ein bisschen Eleganz (also, Strukturierung und Co). Ist es gut, wenn man alle Aufgaben eines Requests und Responses (zum Beispiel Auflistung, Bearbeitung eines Elements (Tabellen in Datenbank)) in einem Servlet macht, also inkl. der Ausgabe (hier XSLT)? Oder sollte man nur Daten im Servlet bearbeiten und erstellen, die Ausgabe aber in einem JSP erledigen? Ich meine, das Stichwort dazu ist Dispatcher.
Ich habe ein kleines Projekt (mein erstes), und derzeit habe ich es so gelöst, das am Ende der doXXX Methoden nur ein "finish" steht, was Ausgabe, Transformation & Co erledigt.

Also wenn ich Effizienz will, dann würd ich versuchen für den Moment wirklich an Zwischenklassen zu sparen. Aber dies ist in der Zukunft ein Schwert, was dir dann die Zeit und Nerven zerschneidet. Man hat zwar am Anfang sehr viel Implementationszeit, weil man recht viel Zeugs drum herum schreiben müsste, aber es lohnt sich, umso mehr du fortschreitest in deiner Entwicklung.
Performant ists sicherlich, wenn du möglichst alles in einem Objekt abhandelst und möglichst versuchst dein Ziel unter wenig Umwegen zu erreichen. Aber das wird ja logisch sein. Deswegen lohnt sich bei Sachen, die performant sein sollen, eher keine MVC-Struktur (meiner Meinung nach), aber dies steht dann im Widerspruch der Effizienz. Man muss dann halt selber irgendwie abwägen, wie weit man alles in jede Richtung treiben will. Ob du dich nun durch mehrere 1000 Zeilen Code in einer Datei quälen willst oder lieber 10 Dateien hast, wo du genau weißt, wofür sie da sind und einen getrennten Aufgabenbereich haben.
Dies ist halt die Eleganz. Sicher jeder sieht dies anders, aber solange man alleine an einem Projekt arbeitet, dann ists einem eigentlich nicht so wichtig, wenn man mehrere Aufgaben in einem Objekt abhandelt. Nur der Programmierer, der daran vielleicht weiter entwickelt, wird sich freuen, wenn er eine klare Struktur erkennen kann und nur mit dem Code belastet wird, den er auch wirklich brauch.
Da JSPs nun die eigentliche View-Schicht in deinem Projekt sein werden, wäre es denk ich besser, wenn du die Ausgabe deiner XSLT-Daten wirklich dahin verlagerst. Wenn du dann mal später irgendwie die Ausgabe anpassen musst (oder auch ein anderer Entwickler), dass siehst du wirklich nur den Code, der ausgegeben werden soll und nicht noch die Controllersachen usw. Ausserdem find ich ne Ausgabe per Servlet ein wenig umständlich. Geht zwar sicher alles per print() und println() aber ob das formschön ist (elegant ist da was anderes)
Ich habs so wie Agmemon gestaltet. Ich hab ein Frontcontroller, der am Start der Applikation eine Hash-Liste bekommt, wo dann für jeden ContentController (bei ihm ists die Command-Klasse) die Daten an diese weiterleitet. So hab ich das Gefühl, dass ich mehr Kontrolle drüber habe, was für Requests man annehmen kann und welche man ablehnt. Der ContentController holt sich dann seine Daten, die er brauch und schickt sie selber an den benötigten Dispatcher (oder was man da auch immer weiter dahinter schalten will (es beschränkt sich weitesgehend auf JSON-Kontrukte)) weiter und dann ist die Sache auch schon fertig. Also der FrontController ist wirklich recht rudimentär gehalten.
Man könnte aber auch irgendwie diese ContentController als eigenes Servlet aufbauen und somit hätte man trotzdem nur das gleiche Ergebnis, nur das man sicherheitsrelevante Sachen, die man vorher untersuchen will, bevor man die Sachen an den Code lässt, in jedem Servlet beachten. Ok man könnte einfach auch ne Klasse erben und dann dort eine generelle Funktion dafür erstellen, die das dann auf alle Servlets überträgt, aber man hat meiner Meinung nach immernoch die Übersichtlichkeit nicht. Aber das ist denk ich ansichtssache.
Ich würd mal pauschal sagen: Wenn du viele Entwickler an einem Projekt arbeiten lassen willst, dann wird es immer wichtiger über eine schön gefächerte Struktur nachzudenken, so dass man auch die Rechte für einzelne Entwickler gut einschränken kann.
Ein Webdesigner, der für dich arbeitet, sollte das Interna nicht interessieren und er muss nur JSP können und über die verfügbaren Daten bescheid wissen. Was in einem Servlet, was mehrere Sachen (also auch die Ausgabe) berwerkstelligt, nicht so leicht geht. Man kann darüber aber sicher ewig diskutieren, weils jeder anders empfindet

Wenn ich mich richtig an das erinnere, was unser prof. uns gesagt hat, dürften JSPs auch gar keinen großen Performanceverlust bringen, da sie in Servlets übersetzt werden.

Hm, ich hab dad derzeit so gelöst, das das Servlet ein Document (w3c) erstellt, und das dann später/am Ende durch den Transformator geschickt wird. Die Ausgabe wird dann mit einem print erledigt.
Also.. viele "prints" hab ich da nicht, aber eben derzeit auch keine jsps.
edit: Ja, der Rest ist klar. Mir ging es primär aber um die Dinge wie Ausgabe und der Existenz von Servlet und JSP. Was die beiden rein technisch können dürfte ich mittlerweile wissen, aber mir ist weniger klar, wann welches für was am Besten ist.

Naja in deinem speziellen Fall wäre es doch eigentlich sinnlos nen JSP zu nehmen oder? Du hast ja sozusagen die Daten mittels Servlet als XML-Document erstellt (soweit ich das verstanden habe) und schickst es durchn transformator mit angegebenen XSL-Stylesheet. Ich hoffe ich habs kapiert
Also ich würde da keine Notwendigkeit von JSP sehen, weil man muss ja nicht unbedingt alles als notwendig sehen. Sozusagen haste dein JSP durch die XSL-Stylesheet ersetzt und das sollte ja reichen. Ich bin zugegebener Maßen ein wenig abgeschweift.

So rein aus Interesse, da ich auch noch mit dem Gedanken spiele: Ich verstehe es so, dass Du serverseitig transformierst. Warum lässt Du den Client nicht die Arbeit machen?

Weil nicht alle Browser bei XSLT gleichermaßen gut können (Implementierung) und es Browser(versionen) gibt, die es gar nicht unterstützen. Man denke nur an Opera 8
Die Anwendung ist relativ klein und ein Tool zum Lernen, daher mache ich mir um Performance keine großen Sorgen wg. dem XSLT.

Naja, also ich würde immer bei einer Ausgabe JSPs einsetzen. Obwohl das nun auch schon wieder veraltet ist: seit es den JSF-Hype gibt, nutzen immer weniger JSP. Allerdings hab ich mich noch nie so wirklich mit JSF auseinandergesetzt. JSP finde ich eigentlich ausreichend.
Servlets sind für die Logik zuständig (per Definition bei MVC bzw. 3-Tier) und reichen die Daten an JSP weiter. RequestDispatcher & Co sollten ja bekannt sein.
Durch Beans wird mit der JSP kommuniziert und mit den entsprechenden Tags ist eine XML-Ausgabe nur wenige Zeilen lang. Man schreibt sich schnell den entsprechenden Tag und die JSP selbst hat letztendlich unter 20 Zeilen (bei einfachen XML's).

Nur mal noch als kleiner Tip am Rande, wenn jetzt gerade vielleicht noch einer "anfängt" sich mit dem Thema zu beschäftigen oder seine Webapplikation in Java zu schreiben, dem empfehle ich dringe sich mal Wicket oder Tapestry anzugucken...
Meiner persönlichen Meinung nach um Meilen besser als JSP oder JSF!!!
Wicket bietet gegenüber von Tapestry halt noch den Vorteil der vollen Unterstützung des MVC-Patterns und einge andere sehr schöne und sinnvolle Funktionen, aber kann halt für einige auch gerade deswegen schon wieder zu oversized sein... Denen empfehle ich dann Tapestry, da es die Trennung von Templates und Code wesentlich besser umsetzt als das "normale" JSP/JSF.

Wenn man mit Tapestry anfangen möchte, sollte man aber gleich mit der Version 5.x (zur Zeit 5.0.5) anfangen... auch wenn es die im Moment nur als Preview-Version gibt. Es hat sich da nämlich einiges am Design im Vergleich zu vorherige Versionen geändert und die neuen Versionen ab 5 sind nicht abwärtskompatibel zu

Hey, wicket sieht ja mal toll aus! Werd ich mir garantiert mal ansehen.
Danke fuer den Tipp!

kein problem!
btw. ich werd mal die nächsten wochen versuchen den java-bereich im entwickler-wiki wieder aus seinem tiefschlaf zu befreien!
angefangen hab ich mal mit einer kleinen abhandlung zu osgi und nem tipp, der mich nen ganzen Arbeitstag gekostet, dass herauszufinden ....

ich glaub wenn mir jemand so kompliziert JSP erklärt hätte .. würd ich jetzt php Webseiten machen

Ein schönes Framework für JSP ist auch icefaces.org
Ist seit einem Jahr Open Source und bietet viele Komponenten: component-showcase.icefaces.org/component-showcase/