Also hier ist der Deal. Ich habe eine Webdienst-WSDL, die ich SOAP-Aufrufe außerhalb meines Unternehmensnetzwerkes vornehmen muss. Der Webservice ist HTTPS SOAP und erfordert ein Clientzertifikat. Ich habe den Client-Code in Java von wsdl2java generiert, und die Dinge scheinen ziemlich gut zu laufen.
Was ich momentan nicht tun kann, ist eine Antwort vom Web-Service durch CXF. Der SSL-Handshake scheint sogar bis zu dem Punkt, an dem CXF versucht, einen HTTP-POST zu machen, einfach abrupt abläuft, wartet aber auf eine Antwort (siehe unten):
%Vor% Wenn ich nun curl oder etwas Ähnliches verwende, kann ich eine Antwort in weniger als einer Sekunde erhalten, also weiß ich, dass der Web-Service nicht fehlerhaft ist. Im Folgenden finden Sie den vollständigen Code, der zum Erstellen des Service-Ports erforderlich ist, einschließlich der Einrichtung mit TLS und einem HTTP-Proxy. Ich habe einen sehr einfachen JUnit-Test, um dies auch zu erstellen und auszuführen:
Ich habe mit einigen Client-Einstellungen herumgespielt, z. B. mit AutoRedirect , AllowChunking usw., ohne Unterschiede, also glaube ich nicht, dass das zu Fehlern führt .
Ich bekomme keine Antwort vom Webservice. Wie kann ich beheben und beheben, was dazu führt, dass CXF eine Zeitüberschreitung verursacht anstatt die Antwort zu erhalten?
OMG! Ich habe es herausgefunden.
Also bin ich durch die Interwebs gegangen und habe dieses kleine Juwel gefunden:
So konfigurieren Sie SoapUI mit Client-Zertifikat-Authentifizierung
Und es verweist auf eine sehr wichtige Notiz von Oracle / Sun:
TLS (Transport Layer Security)
Anwendungen, die eine Neuverhandlungsanfrage von der Gegenstelle erhalten antworten Sie je nach Art der Verbindung:
TLSv1: Eine Warnung Warnmeldung vom Typ "no_renegoveriation (100)" wird sein an den Peer gesendet und die Verbindung bleibt offen.
dann, weiter unten:
Neuverhandlungen können für die Anwendungen, die sie benötigen, erneut aktiviert werden, indem die neue Systemeigenschaft
sun.security.ssl.allowUnsafeRenegotiationauftruegesetzt wird, bevor die JSSE-Bibliothek initialisiert wird. Es gibt mehrere Möglichkeiten, diese Eigenschaft festzulegen:
Befehlszeile:
% java -Dsun.security.ssl.allowUnsafeRenegotiation=true MainJava-Systemsteuerung (Java Plug-in / Java Web Start) - Laufzeitumgebung.
Innerhalb der Anwendung:
java.lang.System.setProperty("sun.security.ssl.allowUnsafeRenegotiation", true);Beachten Sie, dass TLS / SSL-Neuverhandlung nicht auftreten wird, es sei denn beides Client und Server haben Neuverhandlungen ermöglicht.
Also das lange und kurze? System.setProperty("sun.security.ssl.allowUnsafeRenegotiation", "true");
Und Dinge. Gerade. Arbeit.
Ja.
HttpModule sind per HttpApplication. Im Gegensatz zu dem Namensvorschlag wird die Application_End-Methode in global.asax am Ende der Lebensdauer jedes HttpApplicatons NICHT ausgelöst. Es wird am Ende der Lebensdauer aller HttpApplications in der aktuellen AppDomain ausgelöst (wenn die AppDomain abgerissen wird). Dasselbe gilt für die Methode Application_Start.
Es gibt immer nur eine Instanz des Anwendungsobjekts pro Anwendung. Es gibt viele Session-Objekte, die sich jeweils mit Anfragen befassen oder darauf warten, recycelt zu werden.
Der App-Pool wird nicht voll von App-Objekten, da es nur 1 pro Anwendung gibt. Wenn ein App-Pool mehr als eine App hostet, wird es viele geben, und der Pool wird durch das Recyclen des Pools gelöscht. App-Pools verfügen auch über eine Zustandsüberwachung, die den Prozess nach einer bestimmten Anzahl von Anforderungen / Speicherauslastung neu startet. In diesem Fall bleiben bestehende Sitzungen zum Sterben, während eine neue App gestartet wird, um neue Anfragen zu bearbeiten. Wenn alle Sitzungen in der alten App beendet sind, wird die App gelöscht.
Weitere Informationen finden Sie unter MSDN .
Ich habe gerade diesen Beitrag gelesen "Wann ist die IHttpModule.Dispose-Methode gerufen? " Ich fand das
"Die Dispose-Methode führt vor der Entfernung eine abschließende Bereinigung durch des Moduls aus der Ausführungspipeline. "
was bedeuten würde, dass es anwendungsweit ist.
Es ist in Ordnung. Jedenfalls habe ich selbst herausgefunden, dass ich das benutzt habe IHttpModule Dispose-Methode und ein Ereignishandler für die Application.Disposed-Ereignis sollte kaum das gleiche sein. Der erste tritt auf direkt nach dem zweiten.
Ich glaube nicht, dass dies zu 100% korrekt ist, d. h. auf "IHttpModule.Dispose" folgt nicht immer "Application_End". Angenommen, ich habe mehrere Instanzen des Anwendungsobjekts für meine Anwendung ausgeführt, was bedeutet, dass jede Instanz des Anwendungsobjekts einzelne Instanzen von Modulen enthält. Nehmen wir an, es kommt ein Zeitpunkt, an dem der Anwendungspool voll mit Anwendungsinstanzen wird. Was wird dann passieren? Werden die Anwendungsinstanzen nicht einzeln nacheinander verteilt, und in der Kette werden die Module innerhalb der Anwendungsinstanz entsorgt. Jetzt bedeutet diese Entsorgung des Moduls nicht, dass Application_End danach zündet. Die Anwendung läuft noch. Habe ich recht?