Metaner

Danke für den Tipp. Das hat funktioniert! Nachdem ich nun mit keytool alle VeriSign-Zertifikate entfernt habe, läuft meine Anwendung beim Zugiff auf eine Exception. Das genügt mir als Beweis dafür, dass Java zur Validierung das zentral abgelegte Zertifikat von VeriSign verwendet. Hatte vor paar Tagen noch gedacht, dass die Lösung viel komplexer und aufwendiger sein würde. Aber so ist es natürlich auch gut. @flashpixx: Vielen Dank!

Nachdem ich nun eine Nacht über das gelesene schlafen konnte und heute den ein und anderen Artikel gelesen habe konnte ich mir eine Lösung basteln, die ganz ohne Keystore bzw. importiertes Server-Zertifikat auskommt. Mit der nachfolgenden Implementierung funktioniert der Zugriff auch: TrustManagerFactory trustManagerFactory = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm()); trustManagerFactory.init((KeyStore)null); SSLContext customSSLContext = SSLContext.getInstance("SSL"); customSSLContext.init(null, trustManagerFactory.getTrustManagers(), new SecureRandom()); HttpsURLConnection.setDefaultSSLSocketFactory(customSSLContext.getSocketFactory()); Nur frage ich mich jetzt, ob der eingebundene TrustManager auch wirklich das Zertifikat validiert. Zieht der TrustManager jetzt zur Prüfung das Zertifikat des Root-CA (VeriSign) aus "cacerts" heran? Hat jemand eine Idee, wie man soetwas testen kann? Oder gibt es sonstige Kritik an dieser Art der Implementierung? Irgendwie sieht das zu einfach aus.

Danke für den Link ... ich lese aber jetzt erst einmal hier: JavaTM Secure Socket Extension (JSSE) Reference Guide. Ich habe nämlich das Gefühl mehr Grundlagen zu brauchen. Je mehr ich aber lese, desto mehr habe ich das Gefühl nichts mehr zu verstehen. Vielleicht liegts aber auch an der Uhrzeit ... der Kopf ist wohl schon zu voll. Und wie holt man das Zertifikat? :confused: Ich hatte nach meinem letzten Post gedacht, dass das von der SSL-Implementierung in Java gemacht wird und mir als Entwickler das Zertifikat sozusagen auf dem "goldenen Tablett" präsentiert wird. Aber so einfach ist es dann wohl doch nicht? PS: Zu meiner Entlastung vielleicht noch etwas. Bislang hatte ich lediglich mit Java Berührung, wenn es um die Einbindung von Webservices ging. Die WS die ich bislang eingebunden hatte, laufen nicht über SSL. Daher tue ich mich jetzt etwas schwerer. Für die Implementierung der WS benutze ich JAX-WS. Damit habe ich mir auch für die jetzige Aufgabe den entsprechenden WS-Stub erstellt. In der Vergangenheit brauchte ich mir bei den erstellten WS-Clients keine Gedanken um die Verbindungssteuerung machen ... das machte der Stub bzw. das Framework für mich.

Ich ging bei meinen Überlegungen immer davon aus, dass die SSL Verbindung in erster Linie der Verschlüsselung der Kommunikation zwischen beiden Rechnern dient. Aber Du hast natürlich Recht, dass diese Sicherheit nicht viel bringt, wenn die Vertrauenswürdigkeit des Zertifikates nicht geprüft wird. Wenn ich Dich richtig verstanden habe, brauche ich dann einen Keystore in dem das (Root-)Zertifikat ... in meinem Fall wurde das Zertifikat von VeriSign ausgestellt .... import ist. Ich gehe einmal davon aus, dass diese Root-Zertifikate nicht ablaufen bzw. sehr lange gültig sind. Erfolgt die Prüfung des Zertifikates des Webservers dann durch die Implementierung der entsprechenden Prüfmethoden im TrustManager? Wie Du anhand meines Codeschnipsels erkennen kannst, habe ich damit nämlich noch nicht gearbeitet. Das öffentliche Zertifikat des Webservers ist demnach für mich als Entwickler insofern nur von Bedeutung, dass dieses von den Kommunikationskomponenten ermittelt werden und zur Prüfung dem TrustManager übergeben werden kann. Ob "ich" (bzw. die Anwendung) dann diesem Zertifikat vertraut hängt allein und ausschließlich von der Implementierung "meiner" Prüfungen ab? Habe ich das richtig verstanden?

Hallo flashpixx, vielen Dank für den Link. Ich will aber meine Frage vielleicht noch mal etwas anders stellen. Ich bin mir nicht sicher ob ich auf dem Holzweg bin ... aber vielleicht kann mir das jemand sagen. Ich hatte an einen Mechanismus gedacht der dem bei Webservices ähnelt. Dort gibt es doch die Möglichkeit, vom Webserver die Beschreibung (WSDL) zum Webservice abzufragen. Gibt es nicht auch soetwas für öffentliche Zertifikate? Ich kenne doch den Server mit dem ich kommunizieren will ... kann ich von dem nicht "online" das aktuell gültige öffentliche Zertifikat abfragen um meine aktuelle Verbindung damit zu sichern/zu verschlüsseln? In diesem Fall bräuchte es nämlich idealerweise keinen Keystore. Oder habe ich damit zu kurz gedacht? :floet: Gruß Jan PS: Bislang habe ich das öffentliche Zertifikat nur über den Webbrowser und dessen Funktion zum Export des Zertifikates bekommen.

Hallo, ich möchte einen SSL-gesicherten Webservice in eine bestehende Anwendung einbinden. Da ich bislang keine Erfahrung mit SSL hatte, habe ich mir mit diversen Codeschnipseln eine lauffähige Lösung "gebastelt". Dazu habe ich mir das öffentliche Zertifikat vom SSL gesicherten Server besorgt, mir einen Keystore mit dem Keytool erstellt und dort das öffentliche Zertifikat importiert. Soweit so gut. Das Zertifikat des Servers wird jährlich geändert, so dass ich dieses Prozedere jährlich durchführen muss (neues öffentliches Zertifikat besorgen und in Keystore einlesen). Das bekomme ich hin ... aber wie ist es, wenn man die Funktion des Webservice an andere Anwender weitergeben möchte? Ich möchte nicht dem Anwender zumuten, dass dieser sich um die Aktualität des öffentlichen Zertifikates Gedanken machen muss oder gar sich mit Dingen wie Keystore (Keytool) beschäftigen muss. So sieht meine derzeitige SSL-Implementierung für den Client aus: ... KeyStore ks = KeyStore.getInstance("JKS"); char[] keypassword = "...mein Passwort ...".toCharArray(); ks.load(new FileInputStream("...Pfad zu meinem Keystore..."), keypassword); KeyManagerFactory kmf = KeyManagerFactory.getInstance("SunX509"); kmf.init(ks, keypassword); TrustManager[] myTrustManagerTrustAll = new TrustManager[] { new X509TrustManager() { public java.security.cert.X509Certificate[] getAcceptedIssuers() { return null; } public void checkClientTrusted( java.security.cert.X509Certificate[] certs, String authType) { } public void checkServerTrusted( java.security.cert.X509Certificate[] certs, String authType) { } } }; SSLContext customSSLContext = SSLContext.getInstance("SSL"); customSSLContext.init(kmf.getKeyManagers(), myTrustManagerTrustAll, new SecureRandom()); HttpsURLConnection.setDefaultSSLSocketFactory(customSSLContext.getSocketFactory()); ... Kann mir jemand sagen, ob a) es auch einen anderen Weg gibt, mit dem man dynamisch zur Laufzeit (d. h. ohne manuell das öffentliche Zertifikat zu besorgen und ohne einen Keystore mittels Keytool zu administrieren) den SSL-Zugriff eines Clients realisieren kann und wie dies dann aussehen könnte/müsste? Ich erwarte hier keine vollständige Implementierung (wenn es sowas gibt dann nehme ich die natürlich gerne ) ... es wäre aber schön, wenn man mich mit den richtigen "Zauberwörtern" auf den richtigen Weg bringen könnte. Ich habe schon das Internet durchwühlt und die Java-Api durchschaut. Bin aber selbst auf keinen Lösungsansatz gekommen. Gruß Jan PS: Ich würde mich noch als "Java"-Frischling bezeichnen. Daher verzeiht mir bitte, falls ich hier eine unqualifizierte Frage gestellt haben sollte. :floet:

Ich wollte nur kurz die Info los werden, dass es mit einem eigenen Handler und HandlerResolver funktioniert hat. Vielen Dank für den nützlichen Hinweis!

Danke für den Denkanstoss. Ich werde morgen mal versuchen, damit den Zugriff auf den SOAP-Header hinzubekommen. Falls ich selbst nicht zum Erfolg komme oder irgendwo hängen bleibe ... darf ich Dich dann noch einmal "nerven"? Ich benutze einen Web-Service für den ein Benutzerkonto erforderlich ist. Bei jedem WS-Zugriff müssen die Benutzerdaten mitgegeben werden. Nun ist es so, dass das Passwort zum Benutzerkonto nach spätestens x Tagen verfällt und damit der Zugang gesperrt ist. Bislang hatte ich bei jedem WS-Zugriff einen weiteren zusätzlichen WS-Aufruf durchgeführt um eine Information zur Gültigkeitsdauer des Passwortes zu bekommen. Nun hat der Anbieter des Web-Service eine Änderung durchgeführt, bei der nun im Response ein Soap-Header implementiert wurde, in dem genau diese Info steckt. Wenn ich an diese Info komme, würde ich mir für die Zukunft einen 2ten WS-Aufruf sparen und somit Performance gewinnen.

Hallo, vorweg ... ich habe mich bislang nur sporadisch mit Web-Services beschäftigt. Daher verzeiht mir bitte, wenn ich bei meiner Beschreibung evtl. nicht die korrekten Begrifflichkeiten verwende. Ich habe folgendes Problem. Ich benutze einen Web-Service und habe mir mittels wsimport einen entsprechenden Client (Stub) erzeugt. Ich benutze JAX-WS in Version 2.1.X. Der Zugriff funktioniert auch soweit. Nun wurde der Web-Service dahingehend erweitert, dass in der Soap-Nachricht ein <soap:header> mitgeliefert wird. In diesem Soap-Header stehen Informationen, die ich gerne auslesen möchte. Der Web-Service bzw. der erzeugte Stub bietet mir aber keinerlei neue Funktionen um an diese Information zu kommen. Bei meinen Recherchen habe ich schon diverse Lösungsansätze probiert. Allerdings ohne Erfolg. Das einzige was mir bislang gelungen ist, war den HTTP-Header auszulesen ... aber diese Infos brauche ich nicht. :beagolisc Was muss man also tun, um an die Informationen im Soap-Header zu kommen? Gruß Jan

Ein Code-Fragment hatte ich im neuen Posting eingefügt. Das Problem habe ich inzwischen beheben können (siehe neues Posting). Somit kann dieses Thema geschlossen werden.

:valen @ Klotzkopp : 1.000 Dank für Deinen Hinweis mit dem Timing und der daraus abgeleiteten Ursache für mein Problem. Das war der goldene Hinweis um das Problem zu lösen. Ich habe nun das Nachrichtenformat so geändert, dass jetzt (wie Du auch schon empfohlen hattest) die Nachrichtenlänge mitgegeben wird. Der Empfänger puzzelt nun die Nachricht wieder solange zusammen, bis das erwartete Ende erreicht ist. Die Kommunikation zwischen SmallTalk und Java funktioniert nun auch auf den "Problem"-Rechnern zu 100%. Habe dabei auch gleich das mit dem überlesenen 1. Byte korrigiert. Damit wäre auch dieses Mysterium geklärt. :upps @ardcore Danke auch Dir für die Aufklärung in Bezug auf die Data-Frames. Das habe sogar ich verstanden.

Ja, dass hatte ich eigentlich erwartet. :beagolisc Klingt plausibel. Würde tatsächlich erklären, warum es manchmal klappt aber meistens nicht. Soetwas in diese Richtung hatte ich schon vermutet (Timing) aber eher im Hinblick auf die Threads, die die Verarbeitung in SmallTalk und Java übernehmen. Dann werde ich mal versuchen, die Kommunikation um eine Längenprüfung zu erweitern. Bin mal gespannt, ob das zum Erfolg führt. :beagolisc ::floet: Ähm, ja ... kann nicht nur. Ist sogar der Fall. Ich hatte das garnicht mehr auf dem Bildschirm. Als ich damals die SmallTalk-Erweiterung vorgenommen hatte, habe ich mich schon gewundert, warum in Java immer das erste Zeichen der XML-Nachricht "verschluckt" wurde. Weil SmallTalk zu diesem Zeitpunkt eh schon andere merkwürdige Sachen machte, hatte ich das als weitere Eigenheit von SmallTalk hingenommen und seither schicke ich jeder XML-Nachricht ein vorangestelltes (Char(32) -> Leerzeichen) mit. :upps Zu meiner Rechtfertigung (warum ich das so gemacht hatte) war, dass ich bei der Programmierung in Java festgestellt hatte, dass beim ersten Aufruf von #read die Verarbeitung in Java an der Stelle angehalten wurde. Das fand ich ganz toll, da ich so sicherstellen kann, dass Java solange wartet, bis SmallTalk die Verarbeitung des Requests abgeschlossen hat und mit dem Senden der Antwort beginnt. Erst einmal vielen Dank für Deine Unterstützung. Ich werde nun meine Sourcen überarbeiten und prüfen, ob dass den Fehler behebt. Sobald ich neue Erkenntnisses habe werde ich die hier posten. Ich melde mich in jedem Fall noch einmal. Danke und Gruß Jan

Richtig! Auf der einen Seite wird (aus Sicht des Softwareentwicklers) ein SocketWrite-Stream mit Bytes gefüttert und anschließend (wenn die Nachricht komplett "befüllt" wurde) von SmallTalk abgeschickt. Dabei bediene ich mich eine TCP/IP Erweiterung in unserer Entwicklungsumgebung (Object Studio der Firma Cincom) die lt. Manual direkt auf die TCP/IP-API aufsetzt. In Java wird, nachdem der Request abgeschickt wurde, auf die Rückmeldung "gewartet". Wird mit der Rückmeldung begonnen, wird der erzeugte InputStream solange Byte-weise ausgelesen, bis kein Zeichen mehr ankommt. Zum Test hatte ich einmal in dieser Schleife eine Systemprotokollierung eingebaut. Die hat mir gezeigt, dass nur 4380 Bytes gelesen wurden. Das auf dem Transportweg die Nachricht in mehrere Paket aufgeteilt wird/werden muss ist mir klar. Aber das übernimmt für mich doch die Hardware bzw. eine andere (OSI-)-Schicht. Oder etwa nicht? Zum besseren Verständnis poste ich einmal die Java-Methode, die den Request startet und den Response entgegen nimmt. Vielleicht habe ich ja doch eine fehlerhafte Implementierung? public MethodResponse execute(MethodRequest methodRequest) throws Exception { MethodResponse methodResponse = new MethodResponse(methodRequest); Socket socket = this.getSocket(); try { ByteArrayOutputStream outputStream = Adapter.encode(methodRequest); socket.connect(this.getSocketAddress()); OutputStream out = socket.getOutputStream(); out.write(outputStream.toByteArray()); InputStream in = socket.getInputStream(); in.read(); ByteArrayOutputStream aDecStream = new ByteArrayOutputStream(); while (in.available() > 0) { aDecStream.write(in.read()); } Object result = ((MethodResponse)Adapter.decode(aDecStream)).getMethodResult(); methodResponse.setMethodResult(result); if(result instanceof SmalltalkException){ throw ((SmalltalkException)result); } } finally { if(socket != null) socket.close(); } return methodResponse; } Danke und Gruß Jan

Leider besteht das Problem doch noch immer. An der Windows-Registry hats nicht gelegen. Auch nach Neuinstallation tritt das Problem nach wie vor auf. Da ich das Problem weiter analysiert und neue Erkenntnisse gewinnen konnte,habe ich eine neue Meldung zu diesem Problem in Netzwerk-Forum eröffnet. Link: http://forum.fachinformatiker.de/networking-technologies/110331-unvollstaendige-tcp-nachrichten-max-4380-byte.html

Hallo, hierbei handelt es sich um eine Fortsetzung meines Postings Unvollständige Socket-Nachrichten (max. 4379 Byte) aus dem Java-Forum. Da das Problem nun doch nicht gelöst werden konnte und ich davon ausgehe, dass es kein Software/Java Problem ist, suche ich hier bei Euch Netzwerk-Experten nach Rat. Problembeschreibung: Wir haben eine in SmallTalk geschriebene Anwendung die auf Port 8081 einen TCP/IP Listener erzeugt und auf eingehende Verbindungen wartet. Eine in Java geschrieben Programmerweiterung soll sich nun mit diesem TCP/IP Listener verbinden, einen Request senden (reine XML-Daten / ohne HTTP-Header o. ä.) und den Response entgegennehmen. Im Rahmen eines Integrationstestes haben wir nun festgestellt das auf einigen Rechnern der Response (Antwort von SmallTalk an Java) exakt nach 4380 Byte abgeschnitten wird. Wir haben mit 6 Rechnern getestet wobei auf 3 Rechnern dieser Fehler (reproduzierbar) auftritt. Das merkwürdige ist, dass auch auf diesen 3 Rechnern es ab und zu dazu kommt, dass auch Nachrichten über 4380 Byte erfolgreich ankommen. Die Erfolgsquote schwankt zwischen den Rechnern aber erheblich (von ca. 5% -20% erfolgreiche Meldungen > 4380 Byte). Was noch verwirrender ist, ist die Tatsache, dass wir 2 Rechner mit identischer Hard- und Software getestet haben. Auf einem Rechner funktioniert die Kommunikation problemlos wobei der andere Rechner das Problem mit den unvollständigen Nachrichten hat. :eek: Achja, dass die Nachrichten unvollständig ankommen, betrifft auch wirklich nur die Rückmeldung von SmallTalk an Java. Schickt der Java-Client einen Request mit einer Länge über 4380 Byte kommt dieser immer vollständig an. Nur die Rückmeldungen sind von diesem Problem betroffen. Alle Rechner befinden sich im gleichen Netz (wobei das beim Test mit dem Loopback nicht entscheiden dürfte ... aber trotzdem der Hinweis). Außerdem haben wir keine Gemeinsamkeiten unter den 3 fehlerhaften Rechnern entdecken können (sowohl AMD als auch Intel, unterschiedliche Chipsätze etc.). Wir haben auch schon einen der Rechner, auf dem das Problem reproduziert werden kann, neu aufgesetzt. Doch auch das brachte keine Besserung. Alle Rechner laufen mit Windows XP (SP2). Was wir jetzt festgestellt haben ist, dass das Problem nur dann auftritt, wenn beide Anwendungen auf dem selben Rechner laufen und über die Loopback-Adresse kommunizieren (z. B. 127.0.0.1:8081 ). Nur dann tritt das Problem auf den 3 Rechnern reproduzierbar auf. Wir haben auch schon die IP-Adresse 127.0.0.1 durch die IP-Adresse der Netzwerkkarte 10.xxx.xx.xxx ersetzt. Doch auch das brachte keine Besserung. Werden allerdings SmallTalk-Anwendung und Java-Anwendung auf unterschiedliche Rechner gelegt z. B. SmallTalk startet TCP/IP-Listener auf der lokalen IP mit Port 8081 und der Java-Client wird von einem anderen Rechner im Netz gestartet und mit dem Listener verbunden, funktioniert die Kommunikation problemlos.D er Fehler tritt dann garnicht mehr auf. Wir haben auch schon TCP/IP Listener und Java-Client jeweils auf einen der 3 betroffenen Rechnern in diesen Test eingebunden. Der Fehler tritt dann ebenfalls nicht mehr auf. Das Fazit bis dahin: Der Fehler tritt nur bei Verwendung der Loopback-Adresse auf wenn Server-Socket und Client-Socket auf dem gleichen System ausgeführt werden. Der Fehler tritt auch nur mit Nachrichten auf, die von SmallTalk an Java gesendet werden. Der Fehler tritt aber auch dann nicht in 100% der Fällen auf! Weil wir uns das Problem nicht erklären können, haben wir dann Unterstützung aus unserer IT-Abteilung zugezogen. Mit unserer Analyse und den bisher durchgeführten Tests wurde dann eine Protokollierung des Netzwerkverkehrs durchgeführt (Software: Wireshark). Das Problem ist nur, dass sich die Kommunikation auf dem Loopback unter Windows nicht protokollieren läßt (haben auch schon einen Loopback-Adapter als Netzwerk-Device installiert). Wir haben dann als Gegenprobe (dass die Protokollierung grundsätzlich funktioniert) die Protokollierung der Nachrichten durchgeführt, wenn Client-Socket und Server-Socket auf getrennten System ausgeführt werden. Das klappte auch super. Dabei habe ich gesehen, dass die Gesamtnachricht in Paket mit je 1460 Byte aufgeteilt wird. Merkwürdig ist nun, dass die max. Länge der empfangenen Nachricht auf dem Problemrechnern genau 3 dieser Paketgrößen entspricht (3 x 1460 => 4380)? Steckt da ein System hinter? :confused: In den letzten Tagen haben wir nun vergeblich versucht, die Kommunikation auf dem MS-Loopback protokolliert zu bekommen. Haben u. a. auch TCP-Monitor von Apache verwendet und diesen als "Software-Bridge" zwischen Client und Server-Socket eingebunden. Doch TCP-Monitor protokolliert nur HTTP Nachrichten. Da wir keinen HTTP Header in der Kommunikation verwenden, klappte auch dieser Versuch nicht. Daher meine Frage/mein Hilferuf an Euch Experten: Kennt jemand dieses Problem bzw. hat damit einmal zu tun gehabt? Vielleicht kennt jemand von Euch eine Lösung, wie man den Loopback unter Windows XP protokollieren kann. Dass der Loopback unter Linux ohne Probleme "gesnifft" werden kann, wurde mir schon von unseren Admins gesagt. Nur leider sind der SmallTalk-Server als auch "Java-Client" nicht lauffähig unter Linux. Zumindest danke ich Euch schon einmal für das Lesen dieser Problembeschreibung. Gruß Jan

Hallo Cadpax, danke für die schnelle Hilfe. Genau danach habe ich gesucht. Den Hinweis auf Google (i. V. m. Allgemeinbildung) hättest Du Dir aber ruhig verkneifen können. Auch Google hilft einem nicht weiter, wenn man nicht die richtigen "Zauberwörter" eingibt. Schau doch mal was man so findet, wenn man "Windowskennung auslesen" bei Google eingibt. Vielleicht wird Dir dann klar, warum ich hier meine Frage gestellt habe. Gruß Jan PS: Gehört "UnterhosenFußball mit Schokoholikern und MeldungsWegKlicker" zur Allgemeinbildung? :floet:

Hallo und Danke für den Tipp, inzwischen haben wir festgestellt, dass das Problem nur auf diesen einen Rechner auftritt. Zwei andere Testsysteme konnten den Fehler nicht reproduzieren. Nach einigen Recherchen hat sich herausgestellt, dass es vor x-Jahren ein Problem in Smalltalk gab (Nachrichten wurden nach 4380 Byte abgeschnitten) woraufhin der Hersteller der Entwicklungsumgebung uns aufforderte zur Problembehebung an der Windowsregistry Änderungen vorzunehmen. Vermutlich hat dies auf diesem System (die Windowsinstallation ist schon 5 Jahre alt) dazu geführt, dass jetzt in Java die Nachrichten nicht mehr vollständig ankommen. Wir werden den Rechner einfach neu aufsetzen und denken, dass sich das Problem damit erledigt hat. Nochmals Danke und Grüße, Jan

Hallo, gibt es eine Möglichkeit (falls ja, welche) um die Windowskennung (Benutzername mit der sich der User unter Windows angemeldet hat) auszulesen? Irgendwie muss es doch möglich sein, durch die VM auf das darunterliegende System zuzugreifen. Oder? Falls es nichts Fertiges gibt, würde der direkte Funktionsaufruf aus Java funktionieren (DLL: advapi32.dll, Function: #GetUserName)? Hat das jemand einmal probiert? Danke und Grüße Jan

Hallo, ich habe das Problem, dass an einen Java-Socket gesendete Nachrichten nach 4379 Zeichen abgeschnitten werden. Bei der Kommunikation wird von Java (Eclipse 3.2, JDK 6.x) ein Client-Socket geöffnet und mit einem Server-Socket (der von einer Smalltalk-Anwendung geöffnet wurde) verbunden. Anschließend wird eine Nachricht gesendet und die Antwort in Java entgegengenommen. Im Augenblick befinden sich beide Anwendungen (Smalltalk/Java) auf einem Rechner. Für die Kommunikation wird die lokale IP-Adresse und der Port 8081 verwendet. Dieses Kommunikationssystem läuft auf meinem Rechner prima (Windows XP, SP2) und kommt auch mit größeren Nachrichten (getestet mit bis zu 80KB) gut zurecht. Ich habe noch ein zweites System, dass ebenfalls identisch eingerichtet ist (Windows XP, SP2, ...) und auch im gleichen Netzwerk hängt. Werden auf diesem System jedoch Nachrichten zwischen der Smalltalk-Anwendung und Java (Eclipse) ausgetauscht (ebenfalls lokal), so kommen in Java max. 4379 Bytes an obwohl die Nachricht von der Smalltalk-Anwendung nachweislich vollständig abgeschickt wurde. Was also auf dem einen System prima funktioniert, klappt auf diesem garnicht. Da ich mit Java noch nicht viel Übung habe, bräuchte ich von Euch einen Rat, wie ich das Problem nun analysieren kann. Gibt es einen TCP/IP Sniffer o. ä. den ich in Eclipse einbinden kann, um ggf. über die Nachrichtenpakete mehr Informationen zu bekommen? Oder kennt vielleicht jemand von Euch das Problem und hat eine Lösung für mich? Über eine Rückmeldung würde ich mich sehr freuen. Danke und lieben Gruß Jan

Uii, nach 4 Jahren wird dieser Thread wieder hochgeholt. Dann nutze ich dies doch mal um meine Angaben aus 2003 kurz zu aktualisieren. Mein Arbeitgeber und mein Tätigkeitsfeld sind gleich geblieben. Schwerpunkt ist die Softwareentwicklung (Smalltalk und Java). Inzwischen bin ich verheiratet und habe 1 Tochter. Mein aktuelles Jahresgehalt beträgt aktuell 42.900 Euro bei 13 Gehältern. Es sind keine variablen Gehaltsbestandteile vereinbart. Überstunden können abgefeiert oder ausbezahlt werden. Gruß Jan

Hallo Monty, dank Dir trotzdem für Deine Antwort. Das mit dem "^" am Anfang des Ausdrucks war mir auch nicht bekannt. Habe das nun auch eingebaut, da der Ausdruck sonst fehlerhaft gearbeitet hätte. Habe auch statt (-| ) nun [- ] verwendet. Nochmals Danke & Grüße Jan

Manchmals sollte man nicht voreilig fragen. Habs nun doch selber rausgefunden. Das Zauberzeichen "$" war mir bisher nicht bekannt. Mein Ausdruck lautet nun [A-Za-z]{1,3}(-| )[1-9]{1}[0-9]{0,4}$ Problem somit gelöst!

Moin, ich habe schon viele Informationen zu diesem Thema gefunden und auch das ein und andere gelesen. Allerdings finde ich zu meinem aktuellen Problem keinen Lösungsweg. Da ich aber auch nicht tagtäglich mit regulären Ausdrücken arbeitet, verzeiht mir ggf. meine dumme Frage Ich möchte eine Kennzeichen-Prüfung mit einem regulären Ausdruck durchführen. Als Beispiel habe ich ein Behördenkennzeichen genommen (XX-12345), dass den folgenden Regeln unterliegt. - Es beginnt mit mind. 1 bis max 3 Buchstaben - gefolgt von einem Bindestrich oder Leerzeichen - gefolgt von mind. 1 bis max. 5 Ziffern wobei die erste Ziffer keine Null sein darf. Mein regulärer Ausdruck für diese Prüfung sieht im Augenblick so aus: [A-Za-z]{1,3}(-| )[1-9]{1}[0-9] Die Prüfung geht aber nur bis zur ersten Ziffern. Jetzt kommt mein Problem. Es können nun bis zu 4 weitere Ziffern folgen. Nach spätestens 4 optionalen Ziffern muss aber Schluß sein. Alle Versuche sind bisher bei folgenden Kennzeichen gescheitert: 1. XX-123456 oder XX-12345y (falsch, letztes Zeichen zuviel) 2. XX-123a5 (falsch, Buchstabe statt einer Ziffer) Ich habe auch schon versucht mit dem Ausdruck [^0-9A-Za-z_] bzw. [^\W] zu einem richtigen Ergebnis zu kommen, doch das hat nicht geklappt. Wäre super, wenn mir einer mit etwas Hilfe auf die Sprünge helfen könnte. Im Augenblick stehe ich vor lauter Bäumen den Wald nicht mehr. :confused: Danke & Gruß Jan

Hallo zusammen, wie kann man unter Windows XP nach dem Wake-Up aus dem Ruhezustand eine Anwendung/Programm starten? Die Einbindung in den Task-Planer genügt mir in diesem Fall nicht! Der Autostart wird logischerweise nicht berücksichtig. Gibts irgendeinen ***-Hack mit dem man sowas umsetzen kann. Notfalls müßte ich was selbst programmieren. Aber wo kann ich ansetzen? Die Uptime vom System wird beim Ruhezustand nicht zurückgesetzt. Weiß also nicht, wie und wo ich ansetzen kann. Grund für meine Frage: Zwar speichert XP die Umgebung ab, doch habe ich eine Anwendung, die durch den Ruhezustand Ihre Parameter verändert. Dies kann ich nur durch einen Neustart der Anwendung beheben. Über Hilfe würde ich mich sehr freuen. Gruß, Jan

Wer sagt, das man den Führerschein nicht länger abgeben kann? Bevor ein Betroffener einen Bescheid zugestellt bekommt, wird automatisch eine Abfrage des VZRs (Verkehrszentralregisters) durchgeführt. Von dort wird der Sachbearbeitung mitgeteilt, wieviele Punkte jemand schon hat (vorallem wofür!) und ob noch ein Fahrverbot besteht. Wenn nun die Sachbearbeitung meint, das der Betroffene nicht lernfähig ist ... oder sogar fahrlässig gehandelt hat, dann hat der Sachbearbeiter einen Spielraum um das Fahrbot angemessen zu erhöhen Gruss Metaner