Servlet Zugriff Servlet

servus,

allgemeine angaben:
- benutze Tomcat 6.0.29
- habe in der web.xml die servlet-api-2.5 festgelegt (siehe web.xml unten)

ich habe folgendes Problem:
ich habe ein Applet auf dem tomcat, welches durch eine Methode ein serialized-object an ein servlet übergibt und dort das String-Vektor-Objekt in einer Text-datei auf dem Server abgespeichert werden soll.

Dazu sollte mit folgenden Zeilen die doPost-methode des servlets aufgerufen werden und das objekt 'weggeschrieben' werden:
(diese Zeilen sind innerhalb einer Methode des Applets, welche durch eine Button-Action ausgeführt werden)
Java:
                URL servletURL=New URL("http://hierStehtDieServerAdresse/save"); 

                URLConnection connectToServlet = null;

		try {
			connectToServlet = servletURL.openConnection();
		} catch (IOException e) {
			System.err.println("I/O Error when creating an URLConnection");
		}

		connectToServlet.setDoOutput(true);

		connectToServlet.setRequestProperty("Content-Type",
				"application/x-java-serialized-object");

		ObjectOutputStream urlOutput = new ObjectOutputStream(connectToServlet
				.getOutputStream());
                // obj ist hier das serialized-object
		urlOutput.writeObject(obj);
		urlOutput.flush();
		urlOutput.close();
hier ist mein SaveServlet-code:
Java:
public class SaveServlet extends HttpServlet {

	private void storeData(Vector<String> simulatedData) {
		
		String fileName = getServletContext().getRealPath("").concat(
				"/AppletValues.txt");
		BufferedWriter writer = null;
		try {
			writer = new BufferedWriter(new FileWriter(fileName));
		} catch (IOException e) {
			System.err.println("Server -> I/O Problem: generate Writer");
		}

		try {
			for (Iterator<String> iterator = simulatedData.iterator(); iterator
					.hasNext();) {
				writer.write((String) iterator.next());
				writer.newLine();
			}
		} catch (IOException e) {
			System.err.println("Server -> Write Problem: write in file");
		} finally {
			if (writer != null) {
				try {
					writer.close();
				} catch (IOException e) {
					System.err.println("Server -> I/O Problem: close file");
				}
			}
		}

	}

	public void doPost(HttpServletRequest request, HttpServletResponse response) {

		/**
		 * public abstract class javax.servlet.ServletInputStream extends
		 * java.io.InputStream
		 */
		ServletInputStream in = null;
		try {
			in = request.getInputStream();
		} catch (IOException e) {
			System.err.println("I/O Problem: ServletInputStream");
		}

		ObjectInputStream objReader = null;
		try {
			objReader = new ObjectInputStream(in);
		} catch (IOException e) {
			System.err
					.println("Filter Problem: ObjectInputStream(ServletInputStream)");
		}

		Vector<String> simulatedData = null;
		try {
			simulatedData = (Vector<String>) objReader.readObject();
		} catch (IOException e) {
			System.err.println("Server -> Read Problem: serialized Object");
		} catch (ClassNotFoundException e) {
			System.err
					.println("Server -> Read Problem: object data type not available");
		}
		
		storeData(simulatedData);

		PrintWriter out = null;
		try {
			out = response.getWriter();
		} catch (IOException e) {
			System.err
					.println("Server -> Write Problem: response in OutputStream");
		}
		out.println("data saved");
		out.close();

	} // doPost(...)

}
meine web.xml:
[XML]
<?xml version="1.0" encoding="ISO-8859-1"?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
version="2.5">
<display-name>TestServlet</display-name>
<description>Welcome to MyTestServlet</description>
<servlet>
<servlet-name>save</servlet-name>
<servlet-class>SaveServletNeu</servlet-class>
<servlet-name>load</servlet-name>
<servlet-class>LoadServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>save</servlet-name>
<url-pattern>/save</url-pattern>
<servlet-name>load</servlet-name>
<url-pattern>/load</url-pattern>
</servlet-mapping>
</web-app>
[/XML]

Dabei sind mir ein paar dinge noch ein wenig unklar:
  1. ich habe auf dem Tomcat in dem webApps-ordner meine WEB-INF-datei, in der ich die oben stehende web.xml und das saveservlet in dem classes-ordner habe. mein applet liegt in einem unterorder von webapps mit der aufrufbaren html-datei. mir ist hier unklar, wie der aufruf der der doXXX-Methode geschieht. also was im hintergrund der connectToServlet.getOutputstream()-Methode passiert. ist dies überhaupt die verbindung zum servlet???
  2. falls ich die URL eines Servlets aufrufe, in welchem (in doGet und doPost steht das gleiche) nur "test" ausgegeben wird, kommt der Fehler 'HTTP status 404' und folgende beschreibung: The requested resource (/info) is not available.
  3. mein Applet kann nicht aufgerufen werden, wenn dies nicht in einem unterordner von webapps liegt. warum ist dies so organisiert? Dies verhindert ein URL-aufbau durch die getDocumentbase()-methode, der ich den '/save'-zusatz an die url mit concat(...) anheften wollte.
  4. ich musste bis jetzt immer meine updates des applets umbenennen (applet-klasse sowie damit zusammenhängend die .jar-datei), damit er nicht eine alte version im browser aufruft, welche bereits mit der neuen version überschrieben wurde. müsstes da nicht ein neustarten des tomcats reichen, damit er weis, dass eine neue version vorliegt?
hat jemand deshalb evtl. ein gutes, vollständiges (alle kleinen schritte umfassend) tutorial, wie man die applet-servlet-kommunikation auf dem tomcat realisert (also wo servlet, applet, web-inf etc. liegen müssen, worauf in der web-xml geachtet werden muss)
oder
kann mir evtl die grundsätzlichen beziehungen (der oben genannten probleme), welche man bei der realisierung beachten muss, erläutern?
 
W

wurzelsepp

zu 1.

mit connectToServlet wird nichts weiter gemacht, als einen URL aufzurufen. Es wird also ein Request zu einem Server gesandt. Geht nun ein solcher Request ein, schaut der Tomcat nach, ob sich in einer web.xml ein Pattern befindet, welches auch diesen URL passt. In deinem Fall würde das /save matchen. Dann wird in der web.xml nachgeschaut, welches Servlet nun den Namen "save" hat. Das ist nach deiner Konfiguration die Klasse SaveServletNeu. Diese Klasse wird nun aufgerufen. Kam der Request über GET wird doGet aufgerufen, kam er über POST doPost.

zu 2.
Ein Pattern mit "info" ist nicht konfiguriert und sollte was bewirken?

zu 3.
Das Applet ist unter webapps abzulegen, weil es sich um eine Resource handelt, die der Client runterladen kann/muss. Für unter WEB-INF abgelegte Dateien besteht seitens des Clients kein direkter Zugriff

zu 4.
Deployen & Neustart
 
N

nillehammer

Zu den Punkten 1. bis 3. siehe wurzelsepp's Antworten. Dem ist nichts hinzuzufügen.
javalicious3 hat gesagt.:
4. ich musste bis jetzt immer meine updates des applets umbenennen (applet-klasse sowie damit zusammenhängend die .jar-datei), damit er nicht eine alte version im browser aufruft, welche bereits mit der neuen version überschrieben wurde. müsstes da nicht ein neustarten des tomcats reichen, damit er weis, dass eine neue version vorliegt?
Wenn ein Client eine Resource über eine bestimmte URL bereits geladen hat und diese in seinem Cache liegt, fragt er beim nächsten Aufruf an den Server nur noch, ob die über die URL bekannte Resource sich verändert hat. Nur, wenn das der Fall ist, liefert der Server die neue Resource aus. Ansonsten antwortet er mit einem "not modified" und der Client benutzt die Resource aus seinem Cache.

Dieses Verfahren funktioniert aber bei Dir nicht, weil Du Dir Deinen HTTP-Request selbst zusammenbaust und dieser die dafür benötigten Header nicht enthält. Füge Deinem Request noch einen
Code:
If-Modified-Since
-Header hinzu. Nähere Infos zur Struktur dieses Headers gibts hier: List of HTTP header fields - Wikipedia, the free encyclopedia
[EDIT]
Ups, ich hab gesehen, Du hast das Problem ja garnicht bei der Kommunikation des Applets, sondern beim Aufruf im Browser! Hmm, dann die obige Antwort erstmal nur als Hintergrundinfo. Die passende Antwort suche ich gerade...
[/EDIT]
 
Zuletzt bearbeitet von einem Moderator:
N

nillehammer

So nochmal ich zu 4. Es gibt mehrere mögliche Ursachen dafür, dass die Änderungen nur mit Umbenennung funktionieren. Allen gemeinsam ist, dass Resourcen gecached werden. Als erstes cached der Tomcat serverseitig. Das kannst Du mit
Code:
cachingAllowed="false"
im Context-Element abschalten. Mache dies aber nur in der Entwicklungsumgebung. Probiere das zunächst. Wenn es dann immer noch nicht geht, schlägt ein clientseitiger Cache zu. Dazu dann im Bedarfsfall mehr.
 
DANKE für die schnellen antworten. ich denke, das meine probleme nicht schwerwiegend sind für erfahrene (hatte leider keine erfahrene leute in meiner umgebung :D)

mein hauptproblem leider immernoch:
(zu punkt 2: )
ich habe im mom allgemein beim überlegen die vermutung, dass es probleme gibt, ein servlet überhaupt zu laden. woran kann das liegen?
normalerweise (oder eher gesagt im einfachsten fall) lege ich doch die servletklassen in dem unterordner 'classes' von WEB-INF ab. in WEB-INF liegt noch die web-xml. der WEB-INF-ordner sollte dann doch im webapps-ordner des tomcats liegen. im anschluss sollte bei laufendem server doch über die server-adresse und die url des servlets aus der web.xml das servlet aufgerufen und die zeilen der entsprechenden methode ausgeführt werden (zb. html-code über den printer erzeugen)?
entspricht das den tatsachen?

nun noch im einzelnen nachfragen zu den antworten :oops::

@ wurzelsepp:
zu deinen antorten:
  1. woher weis ich, dass der request von doGet oder doPost kommt? (anhand der der signatur?) -> ich seh vllt grad nicht mehr den wald vor lauter bäumen (vllt zu oft drüber gelesen und zu unkonzentriert, haha)
    also ist ein url-aufruf = request? (= also der outputstream?)
  2. ja, sorry. ich hatte die fehlermeldung von einem anderen servlet geholt, welches ich aus übersichtlichkeitsgründen aus der web.xml rausgenommen habe. die fehlermeldung kam jedoch auch leider bei dem saveservlet...
  3. wenn ich mein applet-jar und die zugehörige html direkt in den webapps ordner ablege, wird nichts mehr ausgeführt. erst wenn ich es in einem unterordner lege, funktioniert es. ist es denn richtig, dass ich die WEB-INF und die unterordner mit den applets direkt in dem wepabbs-ordner ablege?
    Dazu die konkrete nachfrage:
    beißen sich der WEB-INF-ordner und der applet unterordner evtl.???
  4. was beinhaltet das deployen eigentlich alles? macht das der webserver nicht auch automatisch bei jedem neustarten des servers? oder was muss für ein deployment manuell getätigt werden?
@ nilehammer:
wo müsste ein if-modified-statement hinein? in die web.xml? und wofür war die, auch wenn nilehammer es verworfen hat? merkt der webserver auch, wenn sich der inhalt des applets geändert hat, oder nur ob der name sich geändert hat und der alte evtl. nicht mehr verfügbar ist?
 
Zuletzt bearbeitet:
@nillehammer:
ich hatte seid vor deiner letzten antwort meinen post geschrieben:D

So nochmal ich zu 4. Es gibt mehrere mögliche Ursachen dafür, dass die Änderungen nur mit Umbenennung funktionieren. Allen gemeinsam ist, dass Resourcen gecached werden. Als erstes cached der Tomcat serverseitig. Das kannst Du mit
Code:
cachingAllowed="false"
im Context-Element abschalten. Mache dies aber nur in der Entwicklungsumgebung. Probiere das zunächst. Wenn es dann immer noch nicht geht, schlägt ein clientseitiger Cache zu. Dazu dann im Bedarfsfall mehr.
ja, das verstehe ich leider gerade nicht wirklich. java ans sich bin ich im mom schon einigermaßen fit, mit applet-servlet-kommunikation fang ich gerade erst intensiver an.

daher:
wo muss das cachingAllowed-statement hin, in die web.xml?
und die web.xml dann in (bei mir) eclipse editieren?
Mit probiere das zunächst
meintest du, dass ich dann ein neues applet aufspielen soll und dann nochmal testen, ob er auch wirklich das neue applet benutzt?

MFG udn vielen dank für euer engagement! :toll:
 
also ich bin jetzt durch bissl weiterforschen auf neue erkenntnisse gestoßen.

ich hatte mal in der konsole von 'startup.sh' bisschen nachgelesen, und gesehen, dass er immer die WEB-INF aus einem anderen unterordner namens 'wps' benutzt. das erklärt, warum meine servlets aus meiner eigenen WEB-INF-datei keine beachtung gefunden haben.
ich hab dann ein 'Helloworld'-servlet testweise in die classes-datei von wps reingelegt -> hat funktioniert.
jedoch führt er meine eigenen servlets immernoch nicht aus und gibt immernoch die gleiche Fehlermeldung wie in Punkt 2 aus.
Liegt das evtl. an einer fehlenden berechtigung, die vielleicht in einer der ganzen zusatz-dateien in wps irgendwo festgelegt wird? oder liegt es daran, dass mein servlet keinen html-code generiert und ich etwas nicht beachtet habe?

viel lieber wäre mir auch, dass er anstatt der WEB-INF-datei aus dem wps-ordner meinen eigenen WEB-INF-ordner benutzt... wo kann ich das einstellen?

mfg
 
N

nillehammer

woher weis ich, dass der request von doGet oder doPost kommt? (anhand der der signatur?) -> ich seh vllt grad nicht mehr den wald vor lauter bäumen (vllt zu oft drüber gelesen und zu unkonzentriert, haha)
also ist ein url-aufruf = request? (= also der outputstream?)
Die Art des Requests bestimmt der Client. Die häufigsten benutzten sind GET (z.B. normaler Klick auf Links) oder POST (Absenden von Formularen). Der Webcontainer erkennt die Art des Requests und ruft automatisch die entspr. doXXX-Methode im Servlet auf.
ja, sorry. ich hatte die fehlermeldung von einem anderen servlet geholt, welches ich aus übersichtlichkeitsgründen aus der web.xml rausgenommen habe. die fehlermeldung kam jedoch auch leider bei dem saveservlet...
Das liegt an Deiner web.xml. Du musst bei
Code:
<servlet-class>
den voll qualifizierten Klassennamen angeben, also inkl. der Packages. So wie Du es gemacht hast:
[XML]
<servlet-class>SaveServletNeu</servlet-class>
[/XML]
Sucht er nach einer Klasse SaveServletNeu im root-Package, wo es aber bestimmt nicht liegt.
wenn ich mein applet-jar und die zugehörige html direkt in den webapps ordner ablege, wird nichts mehr ausgeführt. erst wenn ich es in einem unterordner lege, funktioniert es. ist es denn richtig, dass ich die WEB-INF und die unterordner mit den applets direkt in dem wepabbs-ordner ablege?
Das deployen unterhalb des webapps-Ordners ist der Standardweg und auf jeden Fall richtig. Alles, was zu Deiner Webanwendung gehört (Java-Klassen, Textdateien, herunterladbare Appletts, Bilder etc.) muss sich unterhalb dieses Ordners befinden. Aber, die Webanwendung direkt in webapps reinkopieren ist nicht richtig. Damit ein Tomcat mehrere Webanwendungen gleichzeitig hosten kann, wird für jede Anwendung im webapps-Ordner noch Unterordner angelegt, der so heißt, wie die Anwendung. Diesen Pfad findet man dann auch in URLs wieder. Es gibt einen Speziall, den Unterordner ROOT. Dort kann man deployen, wenn man keinen extra Pfad in der URL sehen will.
beißen sich der WEB-INF-ordner und der applet unterordner evtl.???
Nein, der WEB-INF-Ordner ist ein wichtiger Ordner, den es unbedingt in jeder Webanwendung geben muss. Aber hier dürfen nur Sachen liegen, die nur serverseitig erreichbar sein sollen. Sachen, die direkt für den Client erreichbar sein sollen (also bspw. auch Applets) dürfen hier drunter nicht liegen.
wo muss das cachingAllowed-statement hin, in die web.xml?
Nein, ins Context-Element. Das kannst Du entweder direkt in der server.xml konfigurieren, oder in einem webapp-spezifischen context.xml-Datei. Wo die ist und wie die Aussieht, findest Du hier: Apache Tomcat Configuration Reference (6.0.35) - The Context Container

Zum Schluss nochmal ein Beispiel:
Du klickst folgenden Link an http://www.meinedomain.de/anwendung1/show?id=1
Der Client macht daraus einen GET-Request zum Tomcat
Der Tomcat schaut nach der Webapp "anwendung1"
Dort schaut (nach einigem anderen), ob es ein Servlet-Mapping für "show" gibt
Er lädt das Servlet und ruft die doGet-Methode auf (,die Du ja geschrieben hast).
Über das Request-Argument dieser Methode kannst Du Dir den url-Parameter id besorgen und dessen Wert "1" auslesen.
 
Zuletzt bearbeitet von einem Moderator:
@nillehammer:
Die Art des Requests bestimmt der Client. Die häufigsten benutzten sind GET (z.B. normaler Klick auf Links) oder POST (Absenden von Formularen). Der Webcontainer erkennt die Art des Requests und ruft automatisch die entspr. doXXX-Methode im Servlet auf.
d.h., dass es abhängig davon ist, was ich übersende? z.b. wird ein string von get und post benutzbar sein, ein objekt nicht unbedingt?

Das liegt an Deiner web.xml. Du musst bei <servlet-class> den voll qualifizierten Klassennamen angeben, also inkl. der Packages. So wie Du es gemacht hast:
[XML]<servlet-class>SaveServletNeu</servlet-class>[/XML]
Sucht er nach einer Klasse SaveServletNeu im root-Package, wo es aber bestimmt nicht liegt.
naja, ich meine ich hatte immer beispiele gefunden, bei denen auch der WEB-INF im webapps liegt und somit der server weis, dass er bei 'serveradresse/servletURL' ein servlet mit entsprechendem mapping aus der classes-datei aufrufen soll, oder irre ich mich da?

ich kann nicht ganz nachvollziehen, wofür dein beispiel am ende der nachricht sein soll?
find grad kein zusammenhang zu meinen beispielen...

wie in meiner letzten nachricht zu lesen ist, bin ich ein wenig weiter gekommen, wobei mir da neue dinge unklar sind:

benutzt tomcat immer ddie WEB-INF aus dem wps-ordner, welcher im webapps liegt? (also ist dieser ordner ein standardordner auf tomcat, von welchem immer der WEB-INF-ordner benutzt wird?
können mehrere WEB-INF-ordner benutzt werden beim startup des servers?
wo kann ich eintragen/einstellen, welche/n WEB-INF-ordner er beim server-start benutzt?
???:L???:L???:L

wie erwähnt, fuktionieren einfache beispiele mit html-generierung auch über das einspielen von einfachen servlets in den WEB-INF-ordner von wps. würde diesen notfalls einfach mitbenutzen für meine sachen...
leider funktionieren meine weiteren servlets, welche keinen html generieren, sondern werte in form einer text-datei abspeichern nicht...

ich habe auch das gleiche beispiel eines saveservlets, was ich von einem freund habe. er meinte, es hat auf jeden fall schonma funktioniert, daher frage ich mich, warum dieses beispiel nicht funktioniert???

das beispiel-servlet:
Java:
import java.io.BufferedWriter;
import java.io.FileWriter;
import java.io.IOException;
import java.io.ObjectInputStream;
import java.io.PrintWriter;
import java.util.Iterator;
import java.util.Vector;

import javax.servlet.ServletInputStream;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

public class SaveServlet extends HttpServlet {

	private void storeData(Vector<String> simulatedData) {
		
		String fileName = getServletContext().getRealPath("").concat(
				"/AppletValues.txt");
		BufferedWriter writer = null;
		try {
			writer = new BufferedWriter(new FileWriter(fileName));
		} catch (IOException e) {
			System.err.println("Server -> I/O Problem: generate Writer");
		}

		try {
			for (Iterator<String> iterator = simulatedData.iterator(); iterator
					.hasNext();) {
				writer.write((String) iterator.next());
				writer.newLine();
			}
		} catch (IOException e) {
			System.err.println("Server -> Write Problem: write in file");
		} finally {
			if (writer != null) {
				try {
					writer.close();
				} catch (IOException e) {
					System.err.println("Server -> I/O Problem: close file");
				}
			}
		}

	}

	public void doPost(HttpServletRequest request, HttpServletResponse response) {

		/**
		 * public abstract class javax.servlet.ServletInputStream extends
		 * java.io.InputStream
		 */
		ServletInputStream in = null;
		try {
			in = request.getInputStream();
		} catch (IOException e) {
			System.err.println("I/O Problem: ServletInputStream");
		}

		ObjectInputStream objReader = null;
		try {
			objReader = new ObjectInputStream(in);
		} catch (IOException e) {
			System.err
					.println("Filter Problem: ObjectInputStream(ServletInputStream)");
		}

		Vector<String> simulatedData = null;
		try {
			simulatedData = (Vector<String>) objReader.readObject();
		} catch (IOException e) {
			System.err.println("Server -> Read Problem: serialized Object");
		} catch (ClassNotFoundException e) {
			System.err
					.println("Server -> Read Problem: object data type not available");
		}
		
		storeData(simulatedData);

		PrintWriter out = null;
		try {
			out = response.getWriter();
		} catch (IOException e) {
			System.err
					.println("Server -> Write Problem: response in OutputStream");
		}
		out.println("data saved");
		out.close();

	} // doPost(...)

}
 
ok, ganz konkret:
MEINT IHR, DASS HIER MÜSSTE FUNKTIONIEREN?


Java:
public class MySaveServlet extends HttpServlet {
	@Override
	protected void doGet(HttpServletRequest request, HttpServletResponse response)
			throws ServletException, IOException {
		
		ServletInputStream in = null;
		try {
			in = request.getInputStream();
		} catch (IOException e) {
			System.err.println("I/O Problem: ServletInputStream");
		}
		ObjectInputStream objReader = null;
		try {
			objReader = new ObjectInputStream(in);
		} catch (IOException e) {
			System.err
					.println("Filter Problem: ObjectInputStream(ServletInputStream)");
		}
		Vector<String> simulatedData = null;

		try {
			simulatedData = (Vector<String>) objReader.readObject();
		} catch (IOException e) {
			System.err.println("Server -> Read Problem: serialized Object");
		} catch (ClassNotFoundException e) {
			System.err
					.println("Server -> Read Problem: object data type not available");
		}
		// speichere die (Vector-) Daten in Datei
		storeData(simulatedData);
	}
	
	public void doPost(HttpServletRequest request, HttpServletResponse response) {

		ServletInputStream in = null;
		try {
			in = request.getInputStream();
		} catch (IOException e) {
			System.err.println("I/O Problem: ServletInputStream");
		}
		ObjectInputStream objReader = null;
		try {
			objReader = new ObjectInputStream(in);
		} catch (IOException e) {
			System.err
					.println("Filter Problem: ObjectInputStream(ServletInputStream)");
		}
		Vector<String> simulatedData = null;

		try {
			simulatedData = (Vector<String>) objReader.readObject();
		} catch (IOException e) {
			System.err.println("Server -> Read Problem: serialized Object");
		} catch (ClassNotFoundException e) {
			System.err
					.println("Server -> Read Problem: object data type not available");
		}
		// speichere die (Vector-) Daten in Datei
		storeData(simulatedData);
	} // doPost(...)

	private void storeData(Vector<String> simulatedData) {
		// konstruiere Pfad zur Datei, in der die Daten gesicherten werden
		String fileName = getServletContext().getRealPath("").concat(
				"/AppletValues.txt");
		BufferedWriter writer = null;
		try {
			writer = new BufferedWriter(new FileWriter(fileName));
		} catch (IOException e) {
			System.err.println("Server -> I/O Problem: generate Writer");
		}
		// lese die Daten aus Vector und speichere sie in die Datei
		try {
			for (Iterator<String> iterator = simulatedData.iterator(); iterator
					.hasNext();) {
				writer.write((String) iterator.next());
				writer.newLine();
			}
		} catch (IOException e) {
			System.err.println("Server -> Write Problem: write in file");
		} finally {
			// ...
			try {
				writer.close();
			} catch (IOException e) {
				// TODO Auto-generated catch block
				e.printStackTrace();
			}
		}
	}

}
der zugriff ist immernoch gleich (siehe erster beitrag aus meiner appletmethode)...

hab das abspeichern mal in doGet und do Post gemacht (ob das so sinnvoll ist, kann ich leider nicht einschätzen:D:oops:)

finde im internet leider auch keine konkreten beispiele, die auf einen fall übertragbar sind...
 
N

nillehammer

d.h., dass es abhängig davon ist, was ich übersende?
Nein, mit den übersendeten Daten hat das nichts zu tun. Es sind halt unterschiedliche Requestmethoden, wie sie in HTTP spezifiziert sind (HTTP/1.1: Method Definitions). Sie haben unterschiedliche Zwecke. Welche Art von Request abgesendet wird hängt vom Client ab. Von dem kommt ja schließlich der Request.
z.b. wird ein string von get und post benutzbar sein, ein objekt nicht unbedingt?
HTTP kennt sowieso nur Strings. D.h. in HTTP gibt es sowas wie ein (Java-)Objekt nicht. Dafür, die Daten eines Java-Objekts in einen sendbaren String und wieder zurück zu wandeln, bist Du selbst verantwortlich.
ich kann nicht ganz nachvollziehen, wofür dein beispiel am ende der nachricht sein soll?
find grad kein zusammenhang zu meinen beispielen..
Aus Deinen bisherigen Fragen habe ich geschlossen, dass Dir nicht klar ist, wie ein Request entsteht, wie er zum Server kommt und was ein Webcontainer damit macht. Zur Verdeutlichung des Ablaufs das Beispiel.
MEINT IHR, DASS HIER MÜSSTE FUNKTIONIEREN?
Das wird nicht funktionieren. Du implementierst es in der doGet. Request.getInputStream ist aber für den Rohzugriff auf den Request-Body. Get-Requests haben überhaupt keinen Body. Mindestens müsste der Code also in doPost. Außerdem glaube ich nicht, dass man direkt aus dem Request-Body Java-Objekte lesen kann. Mag sein, dass es geht. Lass Dir den Body mal mit System.out.println anzeigen.
 
@nillehammer:
mit dem request über doXXX ist mir wirklich noch nicht so richtig klar, bin aber gestern weitergekommen, dass ich über url-eingabe des servlets schon daten auf dem server speicher...

es gab da probleme mit schreibgeschützten dateien, was unter windows 7 ein größeres problem zu sein scheint, wenn man nach den ganzen foreneinträgen darüber geht...

naja, ich bastel mal ein wenig weiter und melde mich bei weiteren problemen...

ABER schonmal noch ein FETTES DANKE, dass du so viel beantwortest, hatte eig am anfang des threads nicht mit so schnellem feedback gerechnet :toll: :applaus:
 
Passende Stellenanzeigen aus deiner Region:

Oben