Biese

@Biese: Was bringt es einem wenn Du das Häckchen deaktivierst und alle Besucher danach gefragt werden.

Von Besuchern hat doch keiner geredet ;-))

... versuchs mal mit WEB-DAV (?).

Kenne mich da aber nicht gut genug mit aus, als dass ich Dir da unterstützung geben könnte.

Alternativ könntest Du, wenn Du nach dem Download gefragt wirst, das Häkchen "...bei diesem Datei-Typ immer fragen..." deaktivieren. Dann wirds beim nächsten Mal direkt geöffnet.

Aber zum speichern brauchst du dann immernoch FTP. ODer (glaub ich jedenfalls) Web-Dav - sofern Access das überhaupt unterstützt.

Wenn ich grade Unsinn rede, macht mich bitte darauf aufmerksam ;-)

Ein Array lässt sich nicht wirklich dynamisch vergrößern. Arrays werden - sofern sie 'ganz normal' angelegt werden - im Stack abgelegt, ein Vector (oder eine verkettete Liste) wird im Heap abgelegt. Der Heap ist dazu da, den speicher selbst und dynamisch zu verwalten.

die C Funktion malloc macht ja bekanntlich speicher im Heap frei. Du könntest Dir - vorausgesetzt Du hast die nötige Langeweile - selbst eine verkettete Liste programmieren. Dazu brauchst Du nur ein paar kleine Zutaten:

Eine Tüte void-Pointer

einen Startpointer

einen null-Pointer

ein Struct, das aus einem Pointer auf ein eben solches struct und wahlweise aus einem Void-Pointer oder einem anderen Wert besteht.

Man mache nun initial Speicher von der größe <struct> frei. Die zurückgelieferte Adresse wird im start-pointer untergebracht. Der im neuen <struct> befindliche Pointer auf ein weiteres <struct> wird nun auf null gesetzt. Kräftig ümrühren und eine halbe Stunde gehen lassen.

Nun macht man erneut speicher von der Größe <struct> frei. Die Adresse aus dem Start-Pointer wird kurz bei seite gelegt. Stattdessen wird die neu gelieferte Adresse in den Startpointer geschrieben. Der nun 'alte' startpointer wird in unserem neuen <struct> in den pointer geschrieben, der auf andere <struct>s zeigt.

Das ganze kommt für 20 Minuten in den Ofen.

Nachdem das ganze gar ist haben wir folgendes: eine LiFo-Pipe. Last in First out. Denn der Startpointer zeigt auf das zuletzt frei gemachte <struct>. Dieses wiederum zeigt auf das zuvor freigemachte <struct>. Diese Liste lässt sich nun solange weiter verfolgen, bis man auf einen null-Pointer stößt. Wir erinnern uns: das erste Element wurde mit einem solchen Nullpointer versehen. Wir sind also am offiziellen Ende unserer Liste.

Zum Desert können wir nun diesem Null-Pointer den Wert des Startpointers zuweisen. Das ganze kommt in den Kühlschrank, und wir haben einen perfekt geschlossenen Kreis.

:-)

So liebe Kinder. Jetzt husch husch ins Bett.

Bis zum nächsten mal,

euer Onkel Biese

Du müsstest mir rechtgeben können das es eigentlich bei keiner Konsistenten Datei der Welt ein Problem geben dürfte.

[Edit: falsches Zitat*g*]

*rechtgeb*

Eine Datei war auch nicht das Problem :-) Es ging um eine TCP Connection.

Öffne die Datei, hole Dir aus der Datei den Stream zum lesen.

Öffne die Verbindung zum Drucker, hole Dir den OutputStream.

Mache evtl. jeweils einen Buffered Reader (TXT Datei) und einen Buffered Writer (TCP Verbindung).

Lese eine Zeile mittels des Readers aus der Datei, schreibe diese Zeile mit Hilfe des Writers in den TCP Stream zum Drucker.

Mach das solange, bis die Datei ganz ausgelesen und gesendet ist.

Schließe die TCP Verbindung.

Schließe die Datei.

Sollte ja nun nicht sooo schwer sein. Programmieren musst Du das schon selbst.

Oder eben, wie Perdi bereits gesagt hat, nicht eilenweise auslesen, sondern eben byte für byte...

Das JDBC Interface Connection hat eine Methode

isClosed()

Du solltest, bevor du eine Verbindung lieferst, prüfen ob sie tatsächlich noch offen ist. Kann ja durchaus sein, dass die Verbindung mittlerweile geschlossen wurde, weil vielleicht über Nacht mal das Netzwerk weg war, o.ä.

guckst Du: http://java.sun.com/j2se/1.3/docs/api/java/sql/Connection.html

Ok, dann hab ich wohl die Klammern nicht mitgezählt...

Und da sag mal einer, dass die Größe nicht zählt *g*

Apropos Größe: die coolste Oracle Fehlermeldung die ich mal gesehen habe:

"Eingefügter Wert zu groß für Spalte" - hrhrhr -eng muss sie sein die Spalte - eng

*ggg*

schau Dir mal deine Stream-Geschichte an.

eigentlich musst Du genau das gleiche machen, nur anders herum ;-))

also nicht mit einem StreamReader, sondern ein Writer - hehe

Der copy befehl bei DOS (besagtes CMD Fenster) öffnet die Datei doch auch zwangsläufig, um sie zu kopieren. Ein Kopierer ist auch nicht in der Lage ein Blatt zu kopieren, wenn mann es nicht hineinlegt...

Du kannst mit Java aber ein wenig schummeln. Wenn niemand mitbekommen soll, dass Du irgendwie an der Datei dran warst (passiert beim lessen soweit ich weiß eh nicht), kannst Du glaube ich alle Zeitstempel der Datei manuell korrigieren.

Versuchs mal so:

String line;

while((line=reader.readLine())!=null){

System.out.println(line);

}

*lol*

siehe Thread...

Letztens habe sie nen Pharao ausgegraben. Der Hatte n Buch ín der Hand, in dem diese Idee schon durchgestrichen war ;-))

hehe

@Crackster.

Wie kommst Du denn nach der Schleife in die IF-Abfrage, wenn Du doch eigentlich garnicht aus der Schleife raus gekommen bist ???

*gübel* Oder hab ich die ganze Zeit das Problem verrafft??

Kannst Du diesen Statusbericht hier mal posten ?

Vielleicht lässt sich da doch irgendwas machen.

Reagiert der Drucker auch auf Befehle, die Du ihm schickst ?

Dann prüf mal, ob es sowas wie ein Protokoll gibt, das diese Kommunikation beschreibt. Vielleicht kannst Du ja Zeilen zählen, und nach n Zeilen abbrechen... irgendwass wird sich schon finden...

Schau mal nach, was das letzte ist, dass du über den Stream geschickt bekommst. Vielleicht schickt Dir der Drucker eine Art "GODDBYE" oder sowas...

Prüfe, ob ein solches Wort am Ende der Zeile vorkommt. Ist das der Fall, dann trenne die TCP Verbindung. Dann sollte das Programm ganz normal aus der Schleife kommen.

String line = reader.readLine();

while(line != null) {

  System.out.println(line);

  if(line.indexOf("GOODBYE-WORT")> -1){

    tcpSocket.close();

  }

  line      = reader.readLine

}

Oh man, funktioniert beides nicht, ich will doch nur eine ganz normale Statusabfrage an den Drucker über TCP/IP schicken, dabei einen Stream benutzen, diesen in einer Schleife auslesen, ohne dass er sich am Ende jedesmal aufhängt, sobald er auf null bzw. auf das Ende stößt, bitte helft mir...

hm... das kann dan wohl daran liegen, dass Du eine Netzwerk verbindung hast... Denn der Stream bleibt solange geöfnet, bis die Verbindung abbricht... damit "Hängt" das programm nicht, sondern wartet, bis neue Infos über den Stream reinkommen...

Das ist nun wieder was anderes...

Das Programm terminiert hier erst dann, wenn Du oder der Drucker die Verbindung abbrechen.

while( !(zeile=reader.readline())!=null)

*räusper*

Ok, das war jetzt wirklich mal eine selten doofe idee :-))

Es muss hier natürlich heißen

while( (zeile=reader.readline())!=null)

(ohne die doppelte negation.. *hüstel* )

Hi,

ein weiterer Haupt-Vorteil ist das Transaktions-management. Der Application-Server bietet die nahezu 100% Transaktionssicherheit. Aber bei kleinen DB Anwendungen sollte das wohl unnötig sein. Da sollte ein einfaches Commit / Rollback als transaktionssicherheit reichen ;-))

tztz...

Ihr könnt die Methode Equals() nicht bei einem Null-Objekt aufrufen. Dann lauft ihr ins offene Nullpointer-Messer !!!

Drum kommt ihr ums !=null nicht herum. Denn wenn die Schleife bei objekt.equals(null) abgebrochen werden soll, kann ja nix dabei herumkommen... denn dann ist das 'Objekt' ja schon null und hat keine Methoden mehr...

Übrigens: ein Reader springt immer eine Zeile weiter, wenn readline aufgerufen wird. Du fragst, ob readline null ergibt, um in die schleife zu kommen ,und in der schleife nochmal readline, um an einen Wert zu kommen. Damit springst Du dann immer 2 Schritte nach vorn. Dann ist klar, dass Du am Ende in einen Fehler läufst...

Probier mal

String zeile=null;

while( !(zeile=reader.readline())!=null){

System.out.rpintln(zeile);

}

Ich glaube, da scheiden sich die Geister...

Leider kann ich Dir keine Literaturquellen geben, die Du möchtest.

Ich kann nur versuchen, ein paar Deiner Fragen zu beantworten.

Der Application-Server ist eine "Middleware", die bestimmte Basisdienste zur Verfügung stellt. Das ist zum Beispiel das Pooling von Datenbank-Verbindungen. Der Programmierer muss sich nicht mehr selbst um die performance und den Aufbau der DB-Verbindung kümmern, sondern bekommt diese in gewünschter Menge vom AS geliefert.

Der AS kümmert sich um einheitliches Logging, usw. Er stellt einfach eine gute Infrastruktur zur Verfügung. Wenn das also benötigt wird (häng von der Komplexität des Systems ab) sollte wohl ein AS verwendet werden.

Application-Server gibt es wie Sand am Meer. Die einen sind besser (Oracle), die anderen schlechter (andere Produkte *gg*)

Es gibt auch Produkte, die sich "application Server" nennen, es aber nicht in vollem Umfang sind. Tomcat ist z.B. so ein Fall. Er stellt zwar viel zur Verfügung, aber eben nicht alles ;-)) (bitte jetzt keine Schlacht über die Pros und Contras anfangen!!)

Der Umgang mit Applikation-Servern ist - meine Meinung als Java Antwickler - mit Java sehr einfach. *g* Also halte ich Java für die Technologie der Wahl. Denn Java bietet sehr viele Frameworks und Schnittstellen zu etablierten Backend Systemen (bzw. anders herum, viele Etablierte Backend Systeme bieten Java Schnittstellen).

Außerdem gibt es eine Reihe von Frameworks, die diverse akademische Entwicklungs-konzepte unterstützen. So ist Struts z.B. ein Framework, um nach dem MVC (Model View Controller) zu arbeiten. Struts ist also ganz oben in der Schicht, darunter liegt vielleicht der Application-Server als Middleware, darunter eine Oracle DB als Datenschicht. Wie die Kommunikation läuft, kannst Du Dir sicher denken ;-)

Reicht das erstmal als Info ??

In dem Zusammehang würde mich auch interessieren, wie ein vollwertiges jar erstellt wird. Bisher "mogel" ich mich mit Zip-files, die ich in .jar umbenenne durch die Programmierung ;-))

Wenn jemand also eine gute referenz hat, immer zu mir.

Vor allem interessiert mich dieses "manifest" (oder wie auch immer). Habe bisher keine brauchbaren Infos ergooglen können.

P.S.: Java schreibt man nicht JAVA - Es ist kein Akronym sondern schlicht und ergreifend der Name einer indonesischen Insel bzw. eines Kaffees

I know... *schäm*

Interessanterweise übrigens die wirtschaftlich wichtigste Insel der Inselgruppe der Sunda-inseln :-) Jakarta ist die Hauptstadt. hehe

Hi.

als erstes würde ich Dir empfehlen, NICHT mit einer schönen Umgebung anzufangen.

Schreib deine Quelltexte per HAnd und kompiliere sie per hand.

Als ganz kleine Erleichterung lasse ich auch mal Text-Pad durchgehen. Das ist ein einfacher Texteditor mit Syntax-Highlighting. Aber er korrigiert den Code nicht, und gibt keine Hilfestellungen.

Ales, was er kann ist Syntax highlighting, und per knopfdruck kompilieren. Das ist - so blöd es klingt - für anfänger viel besser als komplexe Systeme. Denn damit lernst Du JAVA wirklich selbst schreiben.

Alles andere ist gut, wenn Du schon viel kannst.

Hier der Link zu Text-pad: http://www.textpad.com

Installiere vorher das Java JDK ( http://java.sun.com ), und dannach Textpad. Denn dann erkennt Textpad, wo kompiliert werden muss ;-))

Aber mehr Hilfestellungen solltest Du als Anfänger nicht verwenden!

Ich glaube, mit Autowerbung waren keine Zettel an Autos gemeint, sondern ein Aufdruck auf deinem eigenen Auto, mit dem Du durch die gegend fährst...

*lol*

Der Server hat die IP, die Du ihm gibst. Alternativ hat er die IP, die er vom Provider bekommt. Hängt davon ab, die Du Dein Netzwerk aufbaust...

Wie oben gesagt solltest Du einen Router oder eine Firewall verwenden.

Dort kann man einstellen, dass alle anfragen durch Port 80 weitergeleitet werden, an die interne IP deines Servers.

Bsp.: Öffentliche IP: 123.45.67.89. Interne IP des Routers: 192.168.0.1

IP deines Servers: 192.168.0.2. Einstellungen beim Router: Leite alle Anfragen von außen, die Port 80 (http) betreffen wieter an den Server.

Der Server hat dann eine Server-Software installiert, die auf einem entsprechenden Port lauscht. Zur Installation wirst Du ums Doku-lesen nicht rum kommen...

Hi,

Es gibt zu diesem Zweck (Traffic-Management) u.a. BIG-IP. Das Ding ist in der Lage Sessions zu erkennen, und diese immer an den richtigen Server zu leiten.

Damit kannst Du auch in Hochverfügbaren umgebungen mit Sessions arbeiten.

Denn eine Session gehört ja nur zu einem der beteiligten Server. :-)

http://www.f5.com/f5products/products/bigip/index.html

Ich glaube, dass deine DSL Leitung etwas ungeignet ist.

Denn mit 512 Kbit Upstream (schätze ich mal) ist dein Server sicher unterfordert. Da ist die Leitung der Flachenhals Nummer 1.

Du sagst leider nicht, wobei man Dir genau helfen kann.

Daher ein paar kleine Denkanstöße von mir ;-))

1) Hast Du einen Router / Firewall ? Denn die Anfragen sollten durch Port-Forwarding an den Server weitergeleitet werden. (sofern er nicht direkt an der Leitung hängt. würde ich allerdings auch nicht empfehlen)

2) Weleches OS kommt auf den Server? Warscheinlich Linux ?

3) schnöder Web-server, oder etwas dynamisches ? PHP, JSP, ASP, usw...

Ich empfehle Dir, eine günstige Hardware-Firewall zu holen. Trendware hat ein Produkt, dass Dyn-DNS automatisch erledigen kann, Port-forwarding unterstützt, ... . Kostet ca 100€. Denn mit DSL wird sich deine IP wohl häufig ändern. Ist Dir Dyn-DNS ein Begriff?

Gruß