Laden Sie eine Textdatei vom .Net-HTTP-Client zur Java-REST-API im InputStream-Format hoch

9

Ich habe einen Fall, in dem ich eine Textdatei vom .NET-HTTP-Client zur Java-REST-API im InputStream-Format hochladen möchte. Wenn ich die Java-REST von Postman mit Datei in Form-Data Body getroffen habe, wird die Datei im Java-REST-Service vollkommen in Ordnung empfangen. Wenn ich das gleiche aus dem .NET Client versuche, habe ich einige Ausnahmen wie folgt.

Mein .Net HTTP Client Code ist wie folgt,

%Vor%

Mein Java-REST-Servicecode ist wie folgt,

%Vor%

Wenn ich auf eine REST-API stoße, erhalte ich die Ausnahme sowohl auf der Seite in .Net als auch in Java, die weiter unten beschrieben wird

.Net-Fehlermeldung:

%Vor%

Java Ausnahme:

%Vor%

Können Sie mir bitte den besten Weg vorschlagen, eine Datei vom .Net Client zum Java REST Service zu übertragen.

    
Smita Koparkar 23.12.2016, 15:15
quelle

2 Antworten

2

Die Ausnahme

  

java.lang.NoSuchMethodError:   javax.ws.rs.ClientErrorException.validate (Ljavax / ws / rs / core / Antwort; Ljavax / ws / rs / core / Antwort $ Status $ Familie;) Ljavax / ws / rs / core / Antwort;

bedeutet, dass es versucht, eine Methode zur Laufzeit vom Typ Response validate(final Response response, Response.Status.Family expectedStatusFamily) von der Klasse ClientErrorException zu bekommen, die es nicht finden kann.

Dies passiert im Allgemeinen, wenn Sie Ihre Anwendung mit einer Version Ihrer Bibliothek erstellen und diese gegen eine andere Version ausführen, die nicht kompatibel ist.

Da ich weiß, dass diese Methode seit JAX-RS 2.0 hinzugefügt wurde, glaube ich, dass Sie Ihren Code mit JAX-RS 2.0 oder höher kompiliert haben und Sie eine Version 1.x in Ihrem Klassenpfad haben, der stattdessen zur Laufzeit verwendet wird. Überprüfen Sie den Klassenpfad, der zur Laufzeit verwendet wird, und stellen Sie sicher, dass Sie nur die gleiche Version von JAX-RS haben, die Sie zur Kompilierungszeit verwendet haben.

    
Nicolas Filotto 12.01.2017 16:16
quelle
1

Was wahrscheinlich passiert, ist, dass der Server die Anfrage nicht mag, sich darauf vorbereitet, einen Fehler zu senden, und aufgrund eines Bibliotheksfehlers (wie von Nicolas Filotto angegeben) fehlschlägt. Aus diesem Grund sehen Sie einen generischen HTTP 500-Fehler statt einiger (informativerer) 4XX.

Beheben Sie die fehlende Übereinstimmung der Bibliotheksversion. Dies ist wahrscheinlich eine gute Idee, auch wenn es funktioniert, wenn die Anfrage mit dem übereinstimmt, was der Server erwartet (wie mit Postman gezeigt)

Wenn ich mir die Unterschriften auf beiden Seiten anschaue, könnte ich folgendes denken:

  • Fügen Sie den verbrauchten Inhaltstypen MediaType.MULTIPART_FORM_DATA_TYPE hinzu.

  • Entfernen Sie client.DefaultRequestHeaders.Add("procId", "100"); , da die procId auf dem Pfad erwartet wird, nicht in den Headern.

  • add file als Name des ByteArrayContent :

    %Vor%

Zusätzlich können Sie versuchen, die Expect: 100-continue -Header zu deaktivieren, die standardmäßig von .NET HttpClient verwendet wird, einige Server behandeln das nicht.

%Vor%     
bwt 13.01.2017 13:44
quelle

Tags und Links