Einfache Frage zu servlets und netbeans 6.5

[ernst]

Hallo allerseits,
1)
mit Hilfe der Anleitung
Introduction to Developing Web Applications - NetBeans IDE 6.7 Tutorial
habe ich eine Webapplication eine funktionierende erstellt, die den Tomcat verwendet.
Dort wird aber u.a. die jsp-Technologie verwendet.

2)
Ich will jetzt eine einfache Webapplication erstellen (die z.B. den eingebebenen Namen mit Begrüssung wieder ausgibt), aber ohne die jsp-Technologie (ich will einfach nur mal mit servlets arbeiten). Außerdem will ich den in Netbeans 6.5 integrierten Tomcat 6.0 verwenden, der den bei mir auf der Festplatte installierten Tomcat 6.0 aufruft
Wie kann ich das am einfachsten machen?

mfg
Ernst

 

[Atze]

hi!
also bei einem "nur mit den servlets arbeiten" und auf jsp o.ä. verzichten würdest du ja nurnoch mit dem "backend" arbeiten, du brauchst ja eine technik zur visualisierung. jsp ist da meiner meinung nach schon die einfachste lösung. wenn du auf die jsp-tags verzichtest, und nur reinen java-code und html (also scriptlets) verwendest, wird es zwar nicht unbedingt mvc-treuer, aber für den einstieg vielleicht einfacher.

nur das mit dem tomcat zugriff auf einen anderen tomcat musst du nochmal erklären! irgendwie ist muir nicht ganz klar was du vor hast!? oder meinst du etwa, du möchtest über netbeans deinen selbstinstallierten tomcat verwalten, d.h. starten und stoppen? ich arbeite auschließlich mit eclipse. aber dort gibt es ein tomcat-plugin, in das der eigene server einkonfiguriert werden kann. ich denke unter netbeans läuft es anaolg dazu, musst du vielleicht mal googlen.

 

[ernst]

hi!
also bei einem "nur mit den servlets arbeiten" und auf jsp o.ä. verzichten würdest du ja nurnoch mit dem "backend" arbeiten, du brauchst ja eine technik zur visualisierung. jsp ist da meiner meinung nach schon die einfachste lösung. wenn du auf die jsp-tags verzichtest, und nur reinen java-code und html (also scriptlets) verwendest, wird es zwar nicht unbedingt mvc-treuer, aber für den einstieg vielleicht einfacher.

Was meinst du mit Backend und technik zur visualisierung?

nur das mit dem tomcat zugriff auf einen anderen tomcat musst du nochmal erklären! irgendwie ist muir nicht ganz klar was du vor hast!? oder meinst du etwa, du möchtest über netbeans deinen selbstinstallierten tomcat verwalten, d.h. starten und stoppen? ich arbeite auschließlich mit eclipse. aber dort gibt es ein tomcat-plugin, in das der eigene server einkonfiguriert werden kann. ich denke unter netbeans läuft es anaolg dazu, musst du vielleicht mal googlen.

Du hast recht: Ich habe mich unklar ausgedrückt.
Ich habe zwar den Tomcat 6.0 auf meiner Festplatte, aber er wird dann intern von Netbeans benutzt (gestartet), ohne dass ich mich darum kümmern muss. Ich muss ihn nur mit tools --> servers --> add Server konfigurieren.
Ich habe vor einiger Zeit das Ganze ohne den integrierten Tomcat gemacht.
Das war ein ziemlicher Aufwand (Konfiguration, usw)
Jetzt will ich das Ganze mit dem integrierten Tomcat 6.0 machen und den Aufwand vergleichen.

mfg
Ernst

 

[Spacerat]

Irgendwie kommt mir das Problem bekannt vor. Das scheint aber nicht das Problem von NB zu sein, sondern offenbar von Tomcat. Es sieht so aus, das zwar mehrere Installationen davon möglich sind jedoch nur eine verwendet werden kann. Ich hatte mal vergeblich versucht Tomcat5 und Tomcat6 gleichzeitig auf verschiedenen Ports laufen zu lassen. Die einzige Möglichkeit zwei unabhängige Tomcat-Instanzen zu bekommnen scheint der Tip in der "Tomcat/RUNNING.txt"-Datei zu sein. In Eclipse Galileo mit WebTools funktioniert das jedenfalls prächtig.
@Edit: Ach, es geht gar nicht um zwei Instanzen sondern nur um den Aufwand? Installation von Netbeans mit gebundeltem Tomcat ist definitiv der geringere würd' ich sagen.

 

[Atze]

Was meinst du mit Backend und technik zur visualisierung?

na deine servlets repräsentieren ja deine logik-komponente, sie steuern den ablauf und die internen arbeiten deiner anwendung (das backend). nur von denen ist ja nichts zu sehen, dem user muss ja irgendwie eine oberfläche angeboten werden, mit der er aggieren kann, das sogenannte frontend. dies war ja wie du schon sagtest in dem ersten beispiel jsp. wenn du jetzt darauf verzichten möchtest, wie möchtest du denn dann die daten aus deinem servlet sichtbar machen?

 

[ernst]

na deine servlets repräsentieren ja deine logik-komponente, sie steuern den ablauf und die internen arbeiten deiner anwendung (das backend). nur von denen ist ja nichts zu sehen, dem user muss ja irgendwie eine oberfläche angeboten werden, mit der er aggieren kann, das sogenannte frontend. dies war ja wie du schon sagtest in dem ersten beispiel jsp. wenn du jetzt darauf verzichten möchtest, wie möchtest du denn dann die daten aus deinem servlet sichtbar machen?

1)
Mit dem Browser firefox mache ich die Daten sichtbar:
Wenn man z.B. im Browser (in einem Formular) einen Namen eingibt, wird dieser an den Webserver und an das Servlet weitergegeben.
Das Servlet veranlasst dann z.B. eine Begrüssung mit dem Namen.

2)
Wie kann ich mit Netbeans und dem integrierten Tomcat 6.0 ein Servlet erzeugen?

mfg
Ernst

 

[Atze]

1)
Mit dem Browser firefox mache ich die Daten sichtbar:
Wenn man z.B. im Browser (in einem Formular) einen Namen eingibt, wird dieser an den Webserver und an das Servlet weitergegeben.
Das Servlet veranlasst dann z.B. eine Begrüssung mit dem Namen.

ja, aber was zeigst du im browser??? du musst die daten aus dem servlet doch sichtbar machen, bspw mit html. oder hast du da ne andere technik?

 

[ernst]

Irgendwie kommt mir das Problem bekannt vor. Das scheint aber nicht das Problem von NB zu sein, sondern offenbar von Tomcat. Es sieht so aus, das zwar mehrere Installationen davon möglich sind jedoch nur eine verwendet werden kann. Ich hatte mal vergeblich versucht Tomcat5 und Tomcat6 gleichzeitig auf verschiedenen Ports laufen zu lassen. Die einzige Möglichkeit zwei unabhängige Tomcat-Instanzen zu bekommnen scheint der Tip in der "Tomcat/RUNNING.txt"-Datei zu sein. In Eclipse Galileo mit WebTools funktioniert das jedenfalls prächtig.
@Edit: Ach, es geht gar nicht um zwei Instanzen sondern nur um den Aufwand? Installation von Netbeans mit gebundeltem Tomcat ist definitiv der geringere würd' ich sagen.

Ich verstehe folgendes noch nicht:
Wie ist das mit dem in Netbeans integrierten Tomcat
Existiert dieser völlig unabhängig von dem auf meiner Festplatte gespeicherten, d.h. ist dieser auch dann noch da, wenn ich den auf meiner Festplatte gespeicherten Tomcat lösche, oder ist der integrierte Tomcat nur ein Verweis auf (völlig davon unabhängigen) einen auf der Festplatte gespeicherten Tomcat, den dann eben in Netbeans mit tools --> serers --> add Server konfiguriert wird ?

mfg
Ernst

 

[ernst]

ja, aber was zeigst du im browser??? du musst die daten aus dem servlet doch sichtbar machen, bspw mit html. oder hast du da ne andere technik?

Ich muss eine html-Datei erstellen, in der sich ein Formular befindet (in das ich einen Namen eingeben kann).
Diese html-Datei rufe ich mit dem Browser auf.

mfg
Ernst

 

[Atze]

es ist ja beides möglich! entweder deine nb-version installiert einen eigenen tomcat mit (würde ich der doku entnehmen), oder es existiert nur ein plugin, die auf deinen tomcat zugreift! was wirklich bei dir vorhanden ist weiß ich nicht. aber wenn du deinen "eigenen" tomcat löscht und immernoch einer läuft, wird nb wohl einen mitgebracht haben vielleicht wird dir irgendein netbeans experte weiterhelfen können

aber das mvc konzept

Model View Controller ? Wikipedia

solltest dir mal angucken. vielleicht musst du es nicht direkt streng umsetzten, aber zumindest nachvollziehen können

 

[Atze]

Ich muss eine html-Datei erstellen, in der sich ein Formular befindet (in das ich einen Namen eingeben kann).
Diese html-Datei rufe ich mit dem Browser auf.

ja, das wollte ich doch wissen also nutzt du html + java, oder? in dateien, die n jsp endung haben? ergo, scriptlets

 

[Spacerat]

@Atze

wenn du jetzt darauf verzichten möchtest, wie möchtest du denn dann die daten aus deinem servlet sichtbar machen?

... na aus dem Servlet raus:

(HttpServletResponse) response.getWriter((CharSequence) htmloutput);

@ernst:
1. Siehe oben und / oder JSP-Tutorial - Inhalt
2. ...ähm... Hab' irgendwo gelesen, das NB seit Version 6 standardmässig einen Tomcat dabei hat. Ist es etwa nicht mehr so, wie bei NB mit gebundeltem Tomcat (z.b. NB5 & TC5) das der gebundelte Tomcat nur solange verwendet wird bis ein externer installiert wird?

 

[Atze]

@Atze... na aus dem Servlet raus:

(HttpServletResponse) response.getWriter((CharSequence) htmloutput);

krasse sache war mir neu, danke

 

[Spacerat]

... Was hab' ich da denn verzapft...
...muss natürlich so:

(HttpServletResponse) response.getWriter().write((CharSequence) htmloutput);

...naja, solange man weiss was ich meine, gehts ja...

 

[Atze]

ja, schon ok! bin nur erstaunt, das es so geht. man lernt nie aus

 

[ernst]

@ernst:
1. Siehe oben und / oder JSP-Tutorial - Inhalt

1) Ich weiss nicht, was du mit siehe oben meinst

2) In dem Link finde ich zwar "Anhang II: Servlets - DIe Grundlagen"
Doch hilft mir das nicht weiter:
Ich will wissen, wie man in Netbeans ein Projekt erzeugt, das ohne JSP ein Servelt erzeugt und ob dazu auch gleich die entsprechenden Konfigurationsdateien im integrierten Tomcat erzeugt werden (der intergrierte Tomcat ist nur ein Plugin, ein sogenannter Connector auf einen schon sich auf der Festplatte befindlichen Tomcat).
[/QUOTE]

mfg
Ernst

 

[maki]

Google sagt dir etwas?

Entweder das, oder mehr Geduld

 

[Spacerat]

@ernst: ...mensch, dann sag das doch...
Also eine Tomcat-Anwendung ohne JSP erzeugt man ganz einfach, indem man halt keine JSP-Dateien erzeugt oder durch die Projekterstellung bereits erzeugten JSP-Dateien löscht. Hab' angenommen, das wäre bekannt. "Siehe oben" bezog sich deswegen auf die Beschreibung der Methode, wie man ohne JSP ein Servlet zur Ausgabe bewegt.
JSP ist ansonsten fester Bestandteil eines Servlet-Containers (wie z.B. Tomcat) und kann soweit ich weiss nicht explizit abgeschaltet werden. Wozu auch - Würde ja bedeuten, dass JSP auf dem gesammten Server ausfällt.
Soweit ich mich erinnern kann, werden in Netbeans (genauso wie in Eclipse) die Web-Projekte inklusive Konfigurationen erzeugt. Diese müssten (zumindest "web.xml") aber möglicherweise im Bezug auf "<servlet>" und "<servlet-mapping>" noch angepasst werden.
Netbeans kann (im Gegensatz zu Eclipse) soweit ich weiss auch einen bereits laufenden externen Tomcat-Server erkennen und diesen im Bedarfsfall auch im Debugmodus neu starten. Ist dem nicht mehr so, so muss vor dem Start einer Netbeans-Sitzung (wie bei Eclipse) der Tomcat-Dienst gestoppt werden.

 

[ernst]

@ernst: ...mensch, dann sag das doch...
Also eine Tomcat-Anwendung ohne JSP erzeugt man ganz einfach, indem man halt keine JSP-Dateien erzeugt oder durch die Projekterstellung bereits erzeugten JSP-Dateien löscht. Hab' angenommen, das wäre bekannt. "Siehe oben" bezog sich deswegen auf die Beschreibung der Methode, wie man ohne JSP ein Servlet zur Ausgabe bewegt.

1)
Du meinst also mit oben, deinen Vorschlag:
(HttpServletResponse) response.getWriter().write((CharSequence) htmloutput);
Ist diese Interpretation von mir richtig?

2)
Statt
(HttpServletResponse) response.getWriter().write((CharSequence) htmloutput);
habe ich früher mal folgendes selbstgeschriebenes Servlet benutzt, mit dem ich auch etwas (im Browser) ausgegeben habe:

package packageDoGet1;

import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;

public class ServletDoGet1 extends HttpServlet {

    protected void doGet(HttpServletRequest request, HttpServletResponse response)    
                        throws ServletException, IOException {
        response.setContentType("text/html");
        PrintWriter out = response.getWriter();
        out.println("<html>");
        out.println("<head>");
        out.println("<title>Get-Servlet</title>");
        out.println("</head>");
        out.println("<body>");
        out.println("<h1>Hier die Infos des Clients:</h1>");
        out.println("<h2>NACHNAME:  "+request.getParameter("nachname")+"</h2>");           
        out.println("<h2>VORNAME:  "+request.getParameter("vorname")+"</h2>");           
        // out.println("<a href=\"http://localshost:8080/getMain.html\">Back</a>");
        out.println("<a href=\"http://localshost:8080/getMain.html\">Back</a>");        
        out.println("</body>");
        out.println("</html>");
        out.close();
    }
}

Vermutlich hast du das mit
(HttpServletResponse) response.getWriter().write((CharSequence) htmloutput);
in abgekürzter Schreibweise gemeint.
Ist das richtig?

@ernst: ...mensch, dann sag das doch...
Also eine Tomcat-Anwendung ohne JSP erzeugt man ganz einfach, indem man halt keine JSP-Dateien erzeugt oder durch die Projekterstellung bereits erzeugten JSP-Dateien löscht. Hab' angenommen, das wäre bekannt. "Siehe oben" bezog sich deswegen auf die Beschreibung der Methode, wie man ohne JSP ein Servlet zur Ausgabe bewegt.

Das heißt, ich erzeuge wie folgt eine Webapplication:
File --> New Project --> Java Web --> Webapplication ...
und lösche dann die JSP-Files und probiere dann das mal mit den Servlets hinzubekommen.
Hast du das gemeint?

Ich probiere dies gleich mal aus!

mfg
Ernst

 

[Spacerat]

Bingo...
Aber nicht vergessen... Möglicherweise müssen die Einträge in der "web.xml" selbst editiert werden. Angenommen im Standard-Paket der Webanwendung befindet sich ein Servlet Namens "Dispatcher.class", an welches alle Anfragen auf den Content geleitet werden sollen. Das sähe dann so aus:

  <servlet>
    <servlet-name>dispatcher</servlet-name>
     <servlet-class>Dispatcher</servlet-class>
  </servlet>
  <servlet-mapping>
    <servlet-name>dispatcher</servlet-name>
    <url-pattern>/*</url-pattern>
  </servlet-mapping>

Und? Erschliessen sich schon die interessanten Möglichkeiten in Sachen URL-Rewriting? (Frage rein rethorisch...)
BTW.: "append()", "print()", "println()" und "write()" sind doch kaum zu Unterscheiden.

 

[ernst]

Bingo...
Aber nicht vergessen... Möglicherweise müssen die Einträge in der "web.xml" selbst editiert werden. Angenommen im Standard-Paket der Webanwendung befindet sich ein Servlet Namens "Dispatcher.class", an welches alle Anfragen auf den Content geleitet werden sollen. Das sähe dann so aus:

  <servlet>
    <servlet-name>dispatcher</servlet-name>
     <servlet-class>Dispatcher</servlet-class>
  </servlet>
  <servlet-mapping>
    <servlet-name>dispatcher</servlet-name>
    <url-pattern>/*</url-pattern>
  </servlet-mapping>

Und? Erschliessen sich schon die interessanten Möglichkeiten in Sachen URL-Rewriting? (Frage rein rethorisch...)
BTW.: "append()", "print()", "println()" und "write()" sind doch kaum zu Unterscheiden.

Erfolglos versuche ich verschiedene Dateien zu konfigurieren:
1)
Eine Webapplication kann man mit Hilfe von
Introduction to Developing Web Applications - NetBeans IDE 6.7 Tutorial
erzeugen. Das Projekt heißt bei mir z.B: HelloWeb1
Dann habe ich mal nachgeschaut, was Netbeans so macht...
Unter dem Pfad
C:\Programme\Apache_Tomcat\apache-tomcat-6.0.18\conf\Catalina\localhost
wird die Datei HelloWeb1.xml erzeugt, mit folgendem Inhalt:
-----------------------------------------
<?xml version="1.0" encoding="UTF-8"?>
<Context antiJARLocking="true" docBase="C:\Daten_Austausch\MEINE_SKRIPTE\ProgJava\23_Internet\PROG\HelloWeb1\build\web" path="/HelloWeb1"/>
---------------------------------------
So weit ich das überblicke, ist das das Einzige was Netbeans auf dem Tomcat-Ordner anlegt bzw. konfiguriert.
Es wird also kein web.xml erzeugt.
Wo muss ich ein web.xml erzeugen bzw. wohin kopieren?
Wo muss ich noch andere Konfigurationsdateien erzeugen?

2)
Wenn ich nicht mit
File --> New Project --> Java Web --> Webapplication ...
sondern ganz normal mit
File --> New Project --> Java --> Java Application...
ein Projekt erzeuge und auch nicht den internen Tomcat verwende (sondern einen exteren Tomcat selbst starte und stoppe), dann muss ich selbst auf dem Tomcat-Ordner:
C:\Programme\Apache_Tomcat\apache-tomcat-6.0.18\webapps
Hand anlegen und dort noch verschiedene Dateien und Ornder kopieren (bis alles funktioniert)
Das macht aber Netbeans nicht, Warum?

mfg
Ernst

 

[Spacerat]

Da wird ein temporärer Context für den Server "localhost" erzeugt. Der Contextpfad ist "/HelloWeb1". Wenn ich das nun richtig deute, müsste sich im Verzeichnis "C:\Daten_Austausch\MEINE_SKRIPTE\ProgJava\23_Internet\PROG\HelloWeb1" irgendwo ein Verzeichnis Namens "WEB-INF" finden lassen, in welcher sich wiederum die "web.xml" befindet.

 

[ernst]

Da wird ein temporärer Context für den Server "localhost" erzeugt. Der Contextpfad ist "/HelloWeb1". Wenn ich das nun richtig deute, müsste sich im Verzeichnis "C:\Daten_Austausch\MEINE_SKRIPTE\ProgJava\23_Internet\PROG\HelloWeb1" irgendwo ein Verzeichnis Namens "WEB-INF" finden lassen, in welcher sich wiederum die "web.xml" befindet.

Habe die Konfiguration jetzt - Dank deiner Tipps - so weit hinbekommen, dass ich mein Program aufrufen kann. Alles funktioniert so weit.
Mir ist nur nicht klar, was die ganzen Konfigurationen bewirken.
Was web.xml macht weiß ich. Nur das Zusammenspiel mit den anderen Konfigurationsdateien ist mir unklar.

Hier die 2 Konfig-Dateien:
C:\Programme\Apache_Tomcat\apache-tomcat-6.0.18\conf\Catalina\localhost\TestServlet1.xml
-----------------------------------------------------------
<?xml version="1.0" encoding="UTF-8" ?>
<Context antiJARLocking="true" docBase="C:\Daten_Austausch\MEINE_SKRIPTE\ProgJava\23_Internet\PROG\
TestServlet1\build\web" path="/TestServlet1" />
-----------------------------------------------------------

C:\Daten_Austausch\MEINE_SKRIPTE\ProgJava\23_Internet\PROG\TestServlet1\build\web\WEB-INF\web.xml
-----------------------------------------------------------
...
<servlet>
<servlet-name>Servlet1</servlet-name>
<servlet-class>mypack1.Servlet1</servlet-class>
</servlet>

<servlet-mapping>
<servlet-name>Servlet1</servlet-name>
<url-pattern>/Servlet1</url-pattern>
</servlet-mapping>

</web-app>
-----------------------------------------------------------

und der Inhalt von getMain.html
C:\Daten_Austausch\MEINE_SKRIPTE\ProgJava\23_Internet\PROG\TestServlet1\build\web\getMain.html
-----------------------------------------------------------
<html>
<head>
<title>Datenerfassung</title>
</head>
<body>
<h1>Datenerfassung</h1>
<form action="http://localhost:8080/TestServlet1/Servlet1" method="get">
Vorname : <input type=text name="vorname" size=40 <br>
Nachname: <input type=text name="nachname" size=40 <br>
<input type="submit" "value="Daten an Servlet übertragen">
</form>
</body>
</html>
-----------------------------------------------------------


Was passiert?
Netbeans erstellt beim Erzeugen einer Web-Anwendung automatisch unter dem Ornder conf
den Unterpfad
Catalina\localhost
Es existiert also im Tomcat-Verzeichnis der Pfad:
conf\Catalina\localhost
Darunter erzeugt Netbeans beim Anlegen eines Projekts (z.B. TestServlet1) eine Datei gleichen Namens mit der Endung xml (z.B. TestServlet1.xml).

Was geschieht beim Aufruf einer URL im Browser, wie z.B:
http://localhost:8080/TestServlet1/getMain.html
Der Webserver Tomcat schaut die Datei TestServlet1.xml an
Jetzt weiss ich allerdings nicht mehr weiter und staune nur noch...

mfg
Ernst

 

[Spacerat]

... was gibts da zu staunen? Ein Kilck auf "Daten an Servlet übertragen" werden die Daten halt an das Servlet übertragen... Ok, Spass beiseite, jetzt kommt "ernst"
Das Verzeichnis "localhost" ist ein sog. "CATALINA_BASE"-Verzeichnis. In einem solchen können Webinhalte (Context) pro (V)Server (in diesem Fall "localhost") beschrieben werden, die nicht im Verzeichnis "webapps" liegen. Das ist im Prinzip der ganze Zauber. Auf diese Art ein sich in Entwicklung befindliches Servlet zu "verteilen" macht doch mehr Sinn, als wenn man nach jedem Kompiliervorgang die einzelnen Klassen ständig nach "webapps" kopieren müsste, findest du nicht?

 

[ernst]

... was gibts da zu staunen? Ein Kilck auf "Daten an Servlet übertragen" werden die Daten halt an das Servlet übertragen... Ok, Spass beiseite, jetzt kommt "ernst"
Das Verzeichnis "localhost" ist ein sog. "CATALINA_BASE"-Verzeichnis. In einem solchen können Webinhalte (Context) pro (V)Server (in diesem Fall "localhost") beschrieben werden, die nicht im Verzeichnis "webapps" liegen. Das ist im Prinzip der ganze Zauber. Auf diese Art ein sich in Entwicklung befindliches Servlet zu "verteilen" macht doch mehr Sinn, als wenn man nach jedem Kompiliervorgang die einzelnen Klassen ständig nach "webapps" kopieren müsste, findest du nicht?

Was passiert?
Netbeans erstellt beim Erzeugen einer Web-Anwendung automatisch unter dem Ornder conf
den Unterpfad
Catalina\localhost
Es existiert also im Tomcat-Verzeichnis der Pfad:
conf\Catalina\localhost
Darunter erzeugt Netbeans beim Anlegen eines Projekts (z.B. TestServlet1) eine Datei gleichen Namens mit der Endung xml (z.B. TestServlet1.xml).

Mir ist immer noch nicht klar, was beim Aufruf einer URL im Browser, wie z.B:
http://localhost:8080/TestServlet1/getMain.html
geschieht.
Der Webserver Tomcat schaut zuerst die Datei TestServlet1.xml an (denn wenn ich die lösche funktioniert es nicht mehr).
Wer sagt dem Tomcat, wo er dann getMain.html suchen und an den Browser zurücksenden soll?

mfg
Ernst

 

[Spacerat]

Das erfährt Tomcat aus der Datei die er im Verzeichnis "localhost" ablegt. Das Attribut "docBase" zeigt auf das Verzeichnis in welchem sich das "WEB-INF"-Verzeichnis befindet. Der Server soll den Contextpfad im Attribut "path" als "docBase" interpretieren. Ergo:

   http://localhost:8080/TestServlet1
-> C:\Daten_Austausch\MEINE_SKRIPTE\ProgJava\23_Internet\PROG\TestServlet1\build\web

Di Datei "TestServlet1.xml" selber wird durch einen Tomcat-Restart gelesen. Dieser Restart wird beim Start des Contextes aus NB heraus automatisch durchgeführt.

 

[ernst]

Das erfährt Tomcat aus der Datei die er im Verzeichnis "localhost" ablegt. Das Attribut "docBase" zeigt auf das Verzeichnis in welchem sich das "WEB-INF"-Verzeichnis befindet. Der Server soll den Contextpfad im Attribut "path" als "docBase" interpretieren. Ergo:

   http://localhost:8080/TestServlet1
-> C:\Daten_Austausch\MEINE_SKRIPTE\ProgJava\23_Internet\PROG\TestServlet1\build\web

Di Datei "TestServlet1.xml" selber wird durch einen Tomcat-Restart gelesen. Dieser Restart wird beim Start des Contextes aus NB heraus automatisch durchgeführt.

Mit "Das erfährt Tomcat aus der Datei die er im Verzeichnis "localhost" ablegt" meinst du konkret die Datei "TestServlet1.xml"
Vorgehensweise des Tomcat:
1) Wenn ein Anforderung eintrifft wie:
http://localhost:8080/TestServlet1/getMain.html
dann scannt der Tomcat die erste Zeichenfolge /..../ direkt nach localhost:8080 ab.
Dies ist hier konkret:
TestServlet1
Dann schaut er sich die Datei TestServlet1.xml in Catalina\localhost an.
Dort steht u.a:
docBase="C:\Daten_Austausch\MEINE_SKRIPTE\ProgJava\23_Internet\PROG\TestServlet1\build\web"
path="/TestServlet1" />
was bedeutet, dass z.B. bei einer Anfrage der Form
http://localhost:8080/TestServlet1/yyy/getMain.html
Die Rssource yyy/getMain.html
unter
docBase="C:\Daten_Austausch\MEINE_SKRIPTE\ProgJava\23_Internet\PROG\TestServlet1\build\web"
gesucht wird.
Also konkret die Ressource yyy/getMain.html unter
"C:\Daten_Austausch\MEINE_SKRIPTE\ProgJava\23_Internet\PROG\TestServlet1\build\web\yyy\getMain.html "
Ist das so weit richtig?

Weiter geht es:
Wenn in getMain.html im Formular
<form action="http://localhost:8080/TestServlet1/Servlet1" method="get">
dann die Anfrage
http://localhost:8080/TestServlet1/Servlet1
an den Tomcat gestellt wird, scannt er wieder die erste Zeichenfolge /..../ direkt nach localhost ab.
Dies ist wieder konkret TestServlet1
Anhand der fehlenden Endung html (es heißt ja nicht TestServlet1.html), weiß er, dass Servlet1 ein Servlet ist.
Da Servlet1 ein Servlet ist, sucht er die Ressource nicht direkt unter
docBase="C:\Daten_Austausch\MEINE_SKRIPTE\ProgJava\23_Internet\PROG\TestServlet1\build\web"
sondern unter
"C:\Daten_Austausch\MEINE_SKRIPTE\ProgJava\23_Internet\PROG\TestServlet1\build\web\WEB-INF"
Er verlangt also, dass sich unter
docBase="C:\Daten_Austausch\MEINE_SKRIPTE\ProgJava\23_Internet\PROG\TestServlet1\build\web"
noch der Ordner
WEB-INF
befindet.
Und dann schaut er sich die darunter befindliche Datei
C:\Daten_Austausch\MEINE_SKRIPTE\ProgJava\23_Internet\PROG\TestServlet1\build\web\WEB-INF\web.xml
an.
Er sieht dort u.a. die Einträge:
<servlet-mapping>
<servlet-name>Servlet1</servlet-name>
<url-pattern>/Servlet1</url-pattern>
</servlet-mapping>

Ist das so weit richtig?


Was sagt ihm dann der Eintrag:
<url-pattern>/Servlet1</url-pattern>
Wo sucht er dann Servlet1.class und was bedeutet der path
/Servlet1
bzw. wie steht der path
/Servlet1
im Zusammenhang mit dem path
path="/TestServlet1


mfg
Ernst

 

[Spacerat]

Ja... das lass ich so mal gelten.
Nun schauen wir uns mal "<url-pattern>/Servlet1</url-pattern>" an. Für die Erklärung der Funktion ist "/Servlet1" jedoch unglücklich gewählt. Wenn man das z.B. in "<url-pattern>/servlet1.html</url-pattern>" ändert und anschliessend die URL http://localhost:8080/TestServlet1/servlet1.html an Tomcat sendet, wird das Servlet ebenso ausgeführt. Interessant ist deswegen wie gesagt der Eintrag "<url-pattern>/*</url-pattern>". Absofort wird nur noch das Sevlet benötigt, also weder irgend eine "*.jsp" noch irgend eine "*htm(l)". Alle Anfragen gehen an das Servlet. Und mit der Eingangs vorgestellten Ausgabe-Methode lässt sich folgendes Servlet recht einfach zu einem mächtigen CMS-System ausbauen.

public final class Servlet1
extends HttpServlet
{
  private static final long serialVersionUID = 1L;

  @Override
  protected void doGet(HttpServletRequest request, HttpServletResponse response)
  throws ServletException, IOException
  {
    doRequest(request, response);
  }

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

  private void doRequest(HttpServletRequest request, HttpServletResponse response)
  throws ServletException, IOException
  {
    String requestURI = getServletContext().getContextPath();
    if(requestURI == null) requestURI = "";
    requestURI = request.getRequestURI().replace(requestURI, "");
    while(requestURI.endsWith("/")) requestURI = requestURI.substring(0, requestURI.length() - 1);
    String requestQuery = request.getQueryString();
    if(requestQuery == null) requestQuery = "";
    // requestURI enhält nun den Namen der angefordeten Datei
    // oder einen Leerstring (-> index.html)
    //
    // requestQuery enthält nun alle per GET übergebenen Parameter
    // als String ohne das führende Fragezeichen. Dieser muss nur
    // noch geparsed (zerlegt) werden.
    // ...
  }
}

 

[ernst]

Ja... das lass ich so mal gelten.
Nun schauen wir uns mal "<url-pattern>/Servlet1</url-pattern>" an. Für die Erklärung der Funktion ist "/Servlet1" jedoch unglücklich gewählt. Wenn man das z.B. in "<url-pattern>/servlet1.html</url-pattern>" ändert und anschliessend die URL http://localhost:8080/TestServlet1/servlet1.html an Tomcat sendet, wird das Servlet ebenso ausgeführt. Interessant ist deswegen wie gesagt der Eintrag "<url-pattern>/*</url-pattern>". Absofort wird nur noch das Sevlet benötigt, also weder irgend eine "*.jsp" noch irgend eine "*htm(l)". Alle Anfragen gehen an das Servlet.
[/code]

Das habe ich verstanden:
Mit
http://localhost:8080/TestServlet1/xxx
und
<url-pattern>/xxx</url-pattern>
wird das unter
<servlet-name>Servlet1</servlet-name>
angegeben Servlet mit dem Name Servlet1 aufgerufen und ausgeführt.
Aber:
In welchem Verhältnis steht der path
/xxx
im Zusammenhang mit dem path
path="/TestServlet1
(in TestServlet1.xml)

Befindet sich /xxx diekt unter
/TestServlet1
oder wie ist das zu verstehen?

mfg
Ernst

 

[Spacerat]

Nein. Das Mapping verweist auf das Servlet. "/xxx" ist im Zweifelsfalle also gar nicht vorhanden. Die URL lässt sich wie folgt zerlegen:

http:// -> Protokoll
localhost:8080 -> Server
/TestServlet1 -> Context-Pfad
/* -> Content

Das Verzeichnismapping aus "TestServlet1.xml" verweist sozusagen auf das DocumentRoot-Verzeichnis. Für Servlets existiert in diesem Verzeichnis ein weiteres Verzeichnis "WEB-INF", in welchem sich wiederum die "web.xml" und ein Verzeichnis "classes" befinden. "classes" beinhaltet nun die Klassenstruktur der Web-Anwendung in der von Java gewohnten Paket-Verzeichnis-Struktur. Das DocumentRoot-Verzeichnis kann[/] weitere Dateien wie "*.jsp" oder "*.htm" und / oder Verzeichnisse enthalten. Sobald aber die "web.xml" ein Servlet-Mapping auf eine hier vorhandene Datei beinhaltet wird statt der datei eben das Servlet ausgeführt. Und wenn nun ein Servlet-Mapping etwa so aussieht[XML]<servlet>
<servlet-name>Servlet1</servlet-name>
<servlet-class>mypack1.Servlet1</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>Servlet1</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>[/XML]ist es völlig egal was in der URL hinter "/TestServlet1/" eingegeben wird oder ob sich noch irgend welche anderen Dateien und Verzeichnisse (ausser "WEB-INF") im DocumentRoot befinden, es wird in jedem Fall das "mypack.Servlet1" ausgeführt. Probier es mal aus: Mein Beispielcode oben mit dem Mapping aus diesem Beitrag und ein Breakpoint in Zeile 28. Dann Debuggen und hinter "/TestServlet1/" beliebige Eingaben übergeben.

 

[ernst]

Nein. Das Mapping verweist auf das Servlet. "/xxx" ist im Zweifelsfalle also gar nicht Und wenn nun ein Servlet-Mapping etwa so aussieht[XML]<servlet>
<servlet-name>Servlet1</servlet-name>
<servlet-class>mypack1.Servlet1</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>Servlet1</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>[/XML]ist es völlig egal was in der URL hinter "/TestServlet1/" eingegeben wird oder ob sich noch irgend welche anderen Dateien und Verzeichnisse (ausser "WEB-INF") im DocumentRoot befinden, es wird in jedem Fall das "mypack.Servlet1" ausgeführt. Probier es mal aus: Mein Beispielcode oben mit dem Mapping aus diesem Beitrag und ein Breakpoint in Zeile 28. Dann Debuggen und hinter "/TestServlet1/" beliebige Eingaben übergeben.

Das mit
<url-pattern>/*</url-pattern>
habe ich auch verstanden und ausprobiert. Mir geht es nur darum, wie der Tomacat eine URL interpretiert.
Mit
-------------
<servlet-name>Servlet1</servlet-name>
<url-pattern>/xxx</url-pattern>
---------
und dem Aufruf im Browser:
http://localhost:8080/TestServlet1/xxx
geht der Tomcat wie folgt vor:
1) er scannt die erste Zeichenfolge /..../ direkt nach localhost:8080 ab.
Dies ist hier konkret:
TestServlet1
Dann schaut er sich die Datei TestServlet1.xml in Catalina\localhost an.
Dort steht u.a:
docBase="C:\Daten_Austausch\MEINE_SKRIPTE\ProgJava\23_Internet\PROG\TestServlet1\build\web"
path="/TestServlet1" />
was bedeutet, dass er eine Ressource unter
docBase="C:\Daten_Austausch\MEINE_SKRIPTE\ProgJava\23_Internet\PROG\TestServlet1\build\web"
sucht.

2) Dann scannt der Tomcat als nächstes /xxx
Er muss jetzt entscheiden, ob dies eine html-Datei ist oder nicht.
Dies macht er, indem er zuerst in der web.xml nachschaut, ob er in der url-pattern einen Eintrag findet.
Da er einen findet, ist es also ein Servlet und dieses Servlet sucht er unter dem Pfad:
C:\Daten_Austausch\MEINE_SKRIPTE\ProgJava\23_Internet\PROG\TestServlet1\build\web\WEB-INF
die Datei Servlet.class. Er findet sie unter:
C:\Daten_Austausch\MEINE_SKRIPTE\ProgJava\23_Internet\PROG\TestServlet1\build\web\WEB-INF\classes\mypack1
und führt sie aus.
Findet er sie nicht und die Datei hat eine html-Erweiterung, wie z.B. bei
http://localhost:8080/TestServlet1/getMain.html
dann interpretiert er sie als html-Datei und sucht sie unter:
C:\Daten_Austausch\MEINE_SKRIPTE\ProgJava\23_Internet\PROG\TestServlet1\build\web
Dort findet er sie und führt sie aus.

Frage1
Ist diese Beschreibung richtig?

Frage2
Angenommen, in der Datei TestServlet1.xml in Catalina\localhost steht u.a:
docBase="C:\Daten_Austausch\MEINE_SKRIPTE\ProgJava\23_Internet\PROG\TestServlet1\build\web"
path="/zzzzzz" />

und im Browser wird aufgerufen:
http://localhost:8080/TestServlet1/...
Dann ist dieser Aufruf nicht erfolgreich.
Damit dieser Aufruf erfolgreich ist, muss notwendigerweise in
path="/TestServlet1" />
stehen.
Ist das richtig?

mfg
Ernst

 

[Spacerat]

Das kann man so gelten lassen. Bis auf die Tatsache, das "TestServlet.xml" nur einmal beim Neustart von Tomcat gelesen wird und das darin befindliche Pfad-Mapping im Speicher gehalten wird. Änderungen in dieser Datei müssen also mit einem Neustart von Tomcat verbunden sein. An dem von dir beschriebenen Ablauf ändert das jedoch nichts. Vllt. sollte noch erwähnt werden, dass wenn kein passendes Servlet-Mapping gefunden wurde, eine entsprechende Datei gefunden werden muß, sonst führt der Aufruf zu einem "404"-Fehler.

 

[ernst]

Das kann man so gelten lassen. Bis auf die Tatsache, das "TestServlet.xml" nur einmal beim Neustart von Tomcat gelesen wird und das darin befindliche Pfad-Mapping im Speicher gehalten wird. Änderungen in dieser Datei müssen also mit einem Neustart von Tomcat verbunden sein. An dem von dir beschriebenen Ablauf ändert das jedoch nichts. Vllt. sollte noch erwähnt werden, dass wenn kein passendes Servlet-Mapping gefunden wurde, eine entsprechende Datei gefunden werden muß, sonst führt der Aufruf zu einem "404"-Fehler.

Erst mal vielen Dank für deine Mühe. Ich habe viel im Internet gesucht, aber diese Infos nirgends gefunden.
Was mir noch unklar ist:
Woher weiß eigentlich der Tomcat, ob er meine "Ressourcen" (z.B. Servlets) unter webapps (dort habe ich früher ohne den interen Tomcat mühevoll immer wieder meine Dateien rüberkopiert) oder unter
C:\Programme\Apache_Tomcat\apache-tomcat-6.0.18\conf\Catalina\localhost
suchen soll?

mfg
Ernst

 

[Spacerat]

Bin jetzt nicht ganz sicher, aber ich glaube das wird in der "server.xml" im "conf"-Verzeichnis festgelegt. Kann aber auch sein, das es die ebenfalls dort zu findende "context.xml" war.

 

[ernst]

Bin jetzt nicht ganz sicher, aber ich glaube das wird in der "server.xml" im "conf"-Verzeichnis festgelegt. Kann aber auch sein, das es die ebenfalls dort zu findende "context.xml" war.

Weißt du eine Quelle, wo das alles einfach und mit Beispielen ausführlich beschrieben wird?

mfg
Ernst

 

[maki]

Weißt du eine Quelle, wo das alles einfach und mit Beispielen ausführlich beschrieben wird?

Tomcat ist sehr gut dokumentiert: Apache Tomcat 6.0 - Documentation Index

 

[ernst]

Bingo...
Und? Erschliessen sich schon die interessanten Möglichkeiten in Sachen URL-Rewriting? (Frage rein rethorisch...)
BTW.: "append()", "print()", "println()" und "write()" sind doch kaum zu Unterscheiden.

Ich weiss nicht genau was du mit URL-Rewriting meinst.
Ich habe das so verstanden, dass dies bedeutet, dass Daten an den URL angehängt werden (bei der get Methode).
Oder was verstehst du darunter?

mfg
Ernst

 

[Spacerat]

Bis auf oben vorgestellten Link ist das meiste weniger brauchbar oder in Englisch. Im zweiteren Fall findet man bei google aber genug. Wenn Englisch nicht das Problem ist, gibts sogar die komplette Dokumentation zum download. Index of /dist/tomcat/tomcat-6 (passende Version auswählen und *fulldocs.* herunter laden)
Das Archiv muß nach $CATALINA_HOME/webapps/docs entpackt werden. $CATALINA_HOME ist das Tomcat Installationsverzeichnis. Die Tomcat Startseite kann mit "http://localhost:8080" aufgerufen werden.
@Edit: URL-Rewriting... Eine Web-Technik die Webinhalte nicht nur Suchmaschinenfreundlich macht, sondern auch die Tatsache verschleiern kann, das es sich um eine Webanwendung handelt. Z.B. indem man Sämtliche Verweise in den dynamischen Seiten die Endung html verpasst, so dass der User nicht mehr mitbekommt, das serverseitig eigentlich eine php oder jsp-Seite aufgerufen wird.
@Edit2: Obwohl es im Prinzip bei Servlets das selbe ist wie z.B. beim Apache-HTTP-Daemon, ist es dennoch nicht das gleiche. Bei Servlets können eventuelle Relinks, die beim Daemon manchmal notwendig sind, komplett entfallen.

 

[ernst]

Bis auf oben vorgestellten Link ist das meiste weniger brauchbar oder in Englisch. Im zweiteren Fall findet man bei google aber genug. Wenn Englisch nicht das Problem ist, gibts sogar die komplette Dokumentation zum download. Index of /dist/tomcat/tomcat-6 (passende Version auswählen und *fulldocs.* herunter laden)
Das Archiv muß nach $CATALINA_HOME/webapps/docs entpackt werden. $CATALINA_HOME ist das Tomcat Installationsverzeichnis. Die Tomcat Startseite kann mit "http://localhost:8080" aufgerufen werden.
@Edit: URL-Rewriting... Eine Web-Technik die Webinhalte nicht nur Suchmaschinenfreundlich macht, sondern auch die Tatsache verschleiern kann, das es sich um eine Webanwendung handelt. Z.B. indem man Sämtliche Verweise in den dynamischen Seiten die Endung html verpasst, so dass der User nicht mehr mitbekommt, das serverseitig eigentlich eine php oder jsp-Seite aufgerufen wird.

1) Zu URL-Rewriting:
Meinst du damit, was du mal geschrieben hast?
"Wenn man das z.B. in "<url-pattern>/servlet1.html</url-pattern>" ändert und anschliessend die URL http://localhost:8080/TestServlet1/servlet1.html an Tomcat sendet, wird das Servlet ebenso ausgeführt. "

2) Zu den Quellen:
Meine Meinung:
Entweder sind sie zu mächtig (groß) für mich als Anfänger, oder unverständlich.
Es fehlen einfache Besipiele und die Beschreibung wie Tomcat sucht.

mfg
Ernst

 

[Spacerat]

1) Zu URL-Rewriting:
Meinst du damit, was du mal geschrieben hast?
"Wenn man das z.B. in "<url-pattern>/servlet1.html</url-pattern>" ändert und anschliessend die URL http://localhost:8080/TestServlet1/servlet1.html an Tomcat sendet, wird das Servlet ebenso ausgeführt. "

Richtig...

2) Zu den Quellen:
Meine Meinung:
Entweder sind sie zu mächtig (groß) für mich als Anfänger, oder unverständlich.
Es fehlen einfache Besipiele und die Beschreibung wie Tomcat sucht.

mfg
Ernst

Beispiele sind aber auch bei der offiziellen Doku schon mit dabei (eigentlich schon bei der standard-Installation) http://localhost:8080/examples/servlets/. und die Lektion, wie Tomcat sucht, hast du ja bereits gelernt.

 

[ernst]

Richtig...Beispiele sind aber auch bei der offiziellen Doku schon mit dabei (eigentlich schon bei der standard-Installation) http://localhost:8080/examples/servlets/. und die Lektion, wie Tomcat sucht, hast du ja bereits gelernt.

Vielen Dank an alle für eure Unterstützung.

mfg
Ernst

 

[Spacerat]

Nicht dafür... Viel Spass mit deinen Servlet-Experimenten...