Apache HTTPClient für alle Fälle

[DaBe1812]

Hi,

ich habe eine Anwendung, die auf viele verschieden Systeme per REST zugreift. Und da gibt es dann viele mögliche Kombinationen:

• Login mit erhalt von Token und das dann im Header für alle Folgeaufrufe
• Logindaten immer als Base64 in jedem Aufruf
• POST oder GET

und und und.

Jetzt habe ich eine Klasse gebaut, die eine Methode für POST hat und eine für GET und eben entsprechende Parameter beim Aufruf.

Jetzt habe ich aber die nächste Anwendung dabei und brauche jetzt auch noch DELETE. Jetzt bin ich am überlegen, ob man dafür nicht eine generelle Methode bauen kann und GET/POST/DELETE als Parameter übergibt.

Das hat auch erstmal bis hier ganz gut geklappt:

    public JSONObject executeHttpRequest(String url, boolean isAddition, boolean withAuthHeader, RequestType type) {

        HttpClientContext context = null;
        URI uri = null;
        try {

            if(isAddition) {
                uri = new URI(BASE_URL + url);
                context = buildDefaultContext();
            } else {
                uri = new URI(url);
                context = buildCustomContext(url);
            }
            
            Builder requestBuilder = HttpRequest.newBuilder();
            
            requestBuilder.uri(uri);
            requestBuilder.header(HttpHeaders.ACCEPT, "application/json");
            
            for (String key : headers.keySet()) {
                requestBuilder.header(key, headers.get(key));
            }

            if(withAuthHeader) {
                String authHeader = getAuth();
                requestBuilder.header(HttpHeaders.AUTHORIZATION, authHeader);
            }

            switch(type) {
            case DELETE:
                requestBuilder.DELETE();
                break;
            case GET:
                requestBuilder.GET();
                break;
            case POST:
                requestBuilder.POST(HttpRequest.BodyPublishers.of);
                break;
            }
            
            HttpRequest request = requestBuilder.build();
            
        } catch (SSLException e) {
            LOG.error("SSL Fehler beim Aufruf " + REFERENCESYSTEM.displayName());
            result = "ERROR SSL Fehler beim Aufruf";
        } catch (IOException e) {
            if(REFERENCESYSTEM == ReferenceSystem.FII) {
                LOG.info(e.getMessage());
            }
            LOG.error("Fehler beim HTTPGet für " + REFERENCESYSTEM.displayName() + " ", e);
            result = "ERROR " + e.getMessage();
        } catch (ParseException e) {
            e.printStackTrace();
        }
        
        return "";
    }

Mein Problem ist in Zeile 37, wenn ich beim Post einen Body übergeben muss.
Das ganze System hier oben ist mit java.net gebaut, vorher war es Apache HTTP Client 5 und da hatte ich als POST-Body eine StringEntity.

Wäre schön, wenn die generelle Lösung auch Apache HTTP Client sein könnte, aber alles, was ich finde ist dann immer dieses "statische"

HttpGet httpget = new HttpGet(url);
//oder
HttpPost request = new HttpPost(url);

Ich suche noch eine Überklasse, oder ein Interface, in dem ich das HttpGet oder HttpPost unterbringen kann.

 

[mihe7]

Mein Problem ist in Zeile 37, wenn ich beim Post einen Body übergeben muss.

Was für ein Problem? Du kannst ja z. B. ofString verwenden.

 

[DaBe1812]

Hab ich tatsächlich testweise probiert und für die ersten Tests hat das sehr gut funktioniert. Was ist denn der Vorteil von Apache HttpClient? Wenn morgen die Tests genauso gut gehen, fliegt der Rest aus der Klasse raus.

 

[mihe7]

Was ist denn der Vorteil von Apache HttpClient?

Da kann ich Dir keine verlässliche Antwort geben. Reine Spekulation: java.net.URL bzw. HttpURLConnection ist doch einigermaßen rudimentär und dürfte auch protokollmäßig nicht immer auf dem neuesten Stand gewesen sein. HTTP/2 wird z. B. erst seit (ich meine) Java 11 in der Standardbibliothek unterstützt. Von daher verstehe ich, dass man eine Lib wie Apache HttpClient verwendet hat, die einem das Leben erleichtert oder bestimmte Dinge überhaupt erst möglich gemacht hat.

Heute hast Du im HttpClient von Java SE auch Dinge wie asynchrone Requests. Da ich den Apache-Client nie verwendet habe (ich bin kein Freund externer Abhängigkeiten), kann ich Dir natürlich auch nicht sagen, ob man die Lib heute überhaupt noch benötigt.

Kleiner fun fact: in Android gabs auch mal so einen Http-Client, der einem das Leben erleichtern sollte (war das okhttp?). Jedenfalls durften wir die Apps dann auf java.net umschreiben, weil das Teil zumindest bis Android 4.x kein SNI ("virtuelle Server") unterstützte - java.net dagegen schon

 

[DaBe1812]

Ja, die Umstellung auf Java 11 war letztes Jahr. Dann macht es ja evtl. Sinn jetzt back to the Java-Roots zu gehen. Ich spiel das morgen mal durch und dann setzt ich die "alten" Funktionen einfach mal für die nächste Version auf deprecated und schau mal, was passiert. Und Abhängigkeiten vermeiden bei nem ANT-Projekt, weil MAven einfach nicht funktionieren wollte, macht sowieso Sinn.

 

[mihe7]

Und Abhängigkeiten vermeiden bei nem ANT-Projekt, weil MAven einfach nicht funktionieren wollte, macht sowieso Sinn.

Abhängigkeiten vermeide ich in erster Linie nicht aus technischen Gründen. Ich sehe es einfach nicht ein, z. B. wegen StringUtils eine was weiß ich wie große Apache Lib einzubinden, die dann womöglich noch drei weitere Libs benötigt, um auf einen leeren String zu prüfen. Logging: interessiert mich nicht, macht der Application Server. Zum Teil gehe ich dazu über, einfach System.out zu verwenden (wird vom AS automatisch geloggt). Mit so einem Käse, fünfundzwanzig Logging Frameworks zu konfigurieren, kann ich mich nicht aufhalten. HTTP: reichte mir bislang java.net und der ExecutorService.

Nicht falsch verstehen: nix gegen Libs, aber man zieht sich sowieso schon so viele Abhängigkeiten rein (PDF Verarbeitung, QR-Codes erstellen, usw), da muss ich nicht alles mit rudimentären Käse zuballern, den ich tatsächlich nicht benötige. Hinzu kommt dann auch immer die rechtliche Seite.

Maven wollte nicht funktionieren? Das gibt es eigentlich nicht, außer ihr betreibt irgendwelche Schweinereien im Build.

 

[Oneixee5]

Maven wollte nicht funktionieren? Das gibt es eigentlich nicht, außer ihr betreibt irgendwelche Schweinereien im Build.

Da wäre ich sehr vorsichtig mit so einer Behauptung. Maven kann z.B. nicht mit einigen Proxys. Wir betreiben Proxy-Proxys um mit Maven arbeiten zu können.
Weiterhin gibt es regelmäßig Probleme mit dem lokalen Repository. Manche Libs funktionieren einfach nicht. Dann beginnt man in den Repos per Hand zu löschen, um zu erzwingen, das Libs oder Abhängigkeiten neu geladen werden.
Dann wäre da noch die Dokumentation. Maven ist ein leuchtendes Beispiel für eine schlechte Dokumentation. Deswegen haben auch so viele Leute Probleme damit. Noch schlimmer ist es mit den Plugins. Da ist oft fast gar nichts beschrieben.
Ganz übel ist auch diese furchtbare XML-Syntax. Gradle macht es nicht besser. Bei größeren Projekten ist schon der Aufruf von Maven auf der Kommandozeile mehrere KB lang.
Gerade Leute mit wenig Erfahrung haben da manchmal hart zu kämpfen. Maven ist bei weitem nicht so gut wie sein Ruf. Ich wünsche mir oft eine wirkliche Alternative. Wenn man da zu z.B. npm, yarn oder cargo schaut, dann wird man richtig neidisch.

 

[DaBe1812]

Ich sehe es einfach nicht ein, z. B. wegen StringUtils eine was weiß ich wie große Apache Lib einzubinden,

Ja, da war ich auch manchmal fasziniert, wenn ich über die Maven Online Tools mir EINE Klasse ziehen wollte und dann auf einmal 10 Klassen rumliegen hatte, wegen Abhängigkeiten.

Wir betreiben Proxy-Proxys um mit Maven arbeiten zu können.

Jo, so hat das hier auch angefangen. Erstes "Grüne-Wiese-Projekt". Kein garnix da, der lokale Server total verkorkst, die Firma liefert eine eigene Maven-Config aus, die auf einen eigenen Nexus verweist, in dem extrem wenig drin ist und bis heute ist mein Antrag Primefaces 8 auf zu nehmen nicht bearbeitet worden und mittlerweile bin ich bei PF12.
Da hatte ich dann mit ANT angefangen, weil ich meine Klassen alle selber ziehe und in den Buildpath mit aufnehme.
Letztens habe ich dann wieder mal nen Versuch gestartet zu Maven zurück zu gehen, aber ich bekomme es schon nicht hin, dass er mir ein Build für den Websphere erstellt, weil mir irgendeine Klasse oder so fehlt. Außerdem komme ich nicht an einen generellen Nexus, weil scheinbar der Weg abgeklemmt worden ist.
Ich würde es gerne benutzen, aber nicht mit den ganzen Steinen in meinem Weg, dann lieber Ant, da weiß ich genau, was es tut.

 

[KonradN]

Weiterhin gibt es regelmäßig Probleme mit dem lokalen Repository. Manche Libs funktionieren einfach nicht. Dann beginnt man in den Repos per Hand zu löschen, um zu erzwingen, das Libs oder Abhängigkeiten neu geladen werden.

Also sowas habe ich bisher nicht erlebt muss ich sagen. Aber evtl. irgendwelche Probleme im ganzen Setup? Was genau habt Ihr aufgesetzt wenn Du sagst:

Wir betreiben Proxy-Proxys um mit Maven arbeiten zu können.

Da nur als Info: Diese Probleme hatte ich bisher nie und ich arbeite auch mit Proxies bzw. haben sogar ein eigenes Repository, welches Dinge von Central, die wir brauchen, bereit stellt.

Ganz übel ist auch diese furchtbare XML-Syntax.

Was ist da furchtbar? Man hat ein XSD das die Richtigkeit prüfen kann und so. Das ist ein riesen Vorteil. Das fehlt mir bei anderen Lösungen.

Dann wäre da noch die Dokumentation. Maven ist ein leuchtendes Beispiel für eine schlechte Dokumentation. Deswegen haben auch so viele Leute Probleme damit.

Mag sein, dass die Dokumentation teilweise deutlich besser sein könnte. Aber bisher habe ich alles immer gefunden was ich gesucht habe. Ich darf nicht an das Moditect Plugin denken - das bereitet einem Kopfzerbrechen, aber das liegt auch schlicht an der Komplexität. Und unter dem Strich macht es vor allem jdeps und jlink aufrufe. Und Maven selbst hat eigentlich viel Dokumentation. So gibt es auch mehrere Bücher, die es gut und Einsteigerfrundlich erklären. Ich sehe nur leider zu oft, dass die Leute einfach etwas nutzen wollen ohne es zu verstehen. Und das führt zu vielen Problemen. Aber in Projekten muss man da ja sehr wenig dran machen, so dass ein mit Maven erfahrener Entwickler schon ausreicht.

Gerade Leute mit wenig Erfahrung haben da manchmal hart zu kämpfen.

Aber das ist doch auch überall so. Komplexität ist nun einmal da und lässt sichnur schwer verbergen. Wenn man keinen Schimmer hat, was Maven überhaupt macht und wie es vorgeht, dann hat man Probleme. Ganz klar. Und meiner Erfahrung nach würde es oft schon ausreichen, einfach mal den wikipedia Eintrag zu Maven zu lesen - dann hat man wenigstens den ersten Überblick.

Bei größeren Projekten ist schon der Aufruf von Maven auf der Kommandozeile mehrere KB lang.

Was wird denn da alles angegeben? Das kann ich nicht wirklich nachvollziehen. Kommt da der Punkt mit "wenig Erfahrung" ins Spiel? Denn ich kenne es so, dass Projektweite Dinge in Profilen in der pom sind und lokale EInstellungen in den Settings / Profilen lokal.

Vor allem ist ja ein Vorteil von Maven, dass man da problemlos auf der Kommandozeile den build testen kann. Wenn man da viel angeben müsste, dann wäre das ja kaum möglich.

Evtl. kann es daher durchaus Sinn machen, da evtl. einen Thread zu erstellen, in dem dann Möglichkeiten oder Alternativen beleuchtet werden.

Wenn man da zu z.B. npm, yarn oder cargo schaut, dann wird man richtig neidisch.

Was bieten denn diese Tools, was Dir bei Maven fehlt? Maven ein hat riesen Vorteil: Die klar definierten Lifecycle! Das bietet sonst kaum ein Tool. Evtl. ist genau dieser Aufbau etwas, der Dir missfällt? (Das wäre so der Punkt, wo sich die Geister meiner Erfahrung nach scheiden.) Das war mit der Grund, wieso ich ursprünglich auch auf Gradle gegangen bin und eben nicht auf Maven. Der Wechsel kam aber, als ich mich dann auch mit Maven einmal richtig auseinander gesetzt habe und die Hintergründe verstanden hatte.


Also ganz wichtig: Ich will Dich nicht von Maven überzeugen. Jeder soll nutzen, was er möchte. Und am Ende ist es egal, was im Projekt genutzt wird so es eine breite Unterstützung hat. Ob mein Code durch Maven, Gradle, ant, make, ... übersetzt wird, ist dabei eigentlich egal.

Aber ich würde Deine Punkte gerne näher verstehen.

 

[KonradN]

Kein garnix da, der lokale Server total verkorkst, die Firma liefert eine eigene Maven-Config aus, die auf einen eigenen Nexus verweist, in dem extrem wenig drin ist und bis heute ist mein Antrag Primefaces 8 auf zu nehmen nicht bearbeitet worden und mittlerweile bin ich bei PF12.

Also da ist die Frage: Wieso wurde das nicht aufgenommen? Wenn da ein Repository betrieben wurde, dann wird es da ja irgend einen Grund für gegeben haben. Ich kenne das aus Security Sicht.

==> Da würdest Du aber massive Probleme haben, wenn Du dann das jar anderweitig einbindem würdest. Denn da umgehst Du eine Firmen Sicherheitsvorgabe.

Aber wenn der Punkt nicht gegeben ist und Ihr da nutzen könnt, was ihr wollt:
Wenn Du die jar selbst einbindest -> Warum dann nicht einfach ein eigenes Repository?
a) Es reicht ja schon, die jar Datei im lokalen Repository zu installieren (ein Maven Aufruf)
b) Da es ja für ein Projekt ist: Dann hat das Projekt sein eigenes Repository. Wir nutzen z.B. Reposilite und haben das Versioniert. Dadurch kann man das sehr einfach füllen: einfach start als Proxy, ein Build durchführen mit Internetzugriff, und dann ein git add / commit / push (Setzt natürlich voraus, dass man ein System hat, dass dann auch auf maven central zugreifen darf. Aber wenn die Firma das verhindern will: Da ist der manuelle Weg auch kritisch. Aber der geht natürlich auch - einfach die Dateien herunterladen und dann in Reposilite einstellen.

Und natürlich kann man auch in Maven lokale jar Dateien einbinden. Dann sagt einem Maven bei Build zwar noch, dass man das Projekt nicht in central hochladen sollte, aber das ist dann je eh uninteressant. Das wäre also auch noch ein Weg und dann ist es kein Unterschied zu ant, wo man die jar in einem lib Ordner liegen hat und einbindet.

Wenn ihr mit ant gut klar kommt: Vollkommen in Ordnung. Und es mag Argumente gegen Maven geben. Aber das genannte sehe ich da erst einmal nicht als Grund gegen das Maven Tool selbst.

 

[LimDul]

Also sowas habe ich bisher nicht erlebt muss ich sagen. Aber evtl. irgendwelche Probleme im ganzen Setup? Was genau habt Ihr aufgesetzt wenn Du sagst:


Da nur als Info: Diese Probleme hatte ich bisher nie und ich arbeite auch mit Proxies bzw. haben sogar ein eigenes Repository, welches Dinge von Central, die wir brauchen, bereit stellt.

Oh, da kann ich auch aus Erfahrung berichten. Die meisten Dinge in Maven funktionieren sauber. Aber einen Vaadin Build hinter einem Firmen-Zwangsproxy ans laufen bekommen war eine Vollkatastrophe, hat uns im Projekt gut und gerne 2 Wochen gekostet, inklusiver 2er Bug-Tickets bei Vaadin. Weil nämlich das maven-vaadin-frontenend Plugin fehlerhaft war/ist: https://github.com/vaadin/flow/issues/13831

Allerdings war das nicht alleine Maven schuld - npm & node.js haben auch dazu beitragen das sie Proxy Umgebungsvariablen teilweise nicht berücksichtigt haben etc.

Dieser ganze Build ist derartig scheiße instabil gewesen, das ich mehr als einmal geflucht habe

 

[KonradN]

Oh, da kann ich auch aus Erfahrung berichten.

Erst einmal Danke für den Erfahrungsbericht.

Und solche Erfahrungen hat wohl jeder gemacht, der komplexere Projekte hat und dann gewisse Netzwerk-Problematiken lösen muss.

Aber das sind dann aus meiner Sicht weniger Tool Probleme sondern Netzwerk-Themen.

Da kann ich auch von vielen Dingen berichten - Firmen-Proxy, der eine ntlm Anmeldung benötigt wäre da ein Thema der Vergangenheit. Also nix mit User/Passwort! Da fallen einem dann viele Tools massiv auf die Nase: mvn, npm, git, nuget, ... (Da war dann cntlm die Rettung!)

Zu so Infrastruktur- oder Netzwerkprobleme hatte ich ja auch mal einen Thread erstellt - um nach Möglichkeiten zu fragen (Und da war dann eine Lösung wie die von mir bereits gefundene Reposilite Lösung als übliche Lösung genannt wenn ich mich recht erinnere).


Mein Punkte sind halt:

a) Vieles ist kein Maven Problem. Beispiel: Wennn jemand sagt: Ich nehme ant, denn da liegen die Libraries einfach lokal: Das geht auch mit Maven und daher ist das kein Grund, Maven nicht zu nutzen.

b) Ja, es gibt Unterschiede z.B. zwischen Maven und Gradle (und zu anderen Build Tools). Und da kann jeder bewerten, was er braucht / will / bevorzugt. Das ist vollkommen normal. Man kann auch gerne ein Bashing betreiben, aber dabei sollte man sich bewusst sein, was man kritisiert. Und ich hake halt dasehr gerne nach. Mir geht es nicht darum, Maven zu verteidigen. Ich will nur dazu lernen. Was gibt es für Probleme? Was für Workarounds oder Lösungen gibt es dazu? Daher hake ich da nach. Es geht nicht darum, dass ich irgend einen User überzeugen will. Zumal bestehende Projekte muss man ja nicht umstellen. Wir haben hier auch noch ant im Einsatz für die alten Projekte.

 

[mihe7]

Weil nämlich das maven-vaadin-frontenend Plugin fehlerhaft war/ist

Naja, das ist klar. Wenn ich einen NetBeans Task in ant reinnehme und der NetBeans-Ant-Task fehlerhaft ist, dann läuft ant auch nicht mehr. Das würde ich aber nicht als ant-Problem sondern als NetBeans-Problem sehen.

Das mit dem Proxy kann ich nicht ganz nachvollziehen, das dürfte sich schließlich auch über das JDK regeln lassen, wenns denn sein muss (da gibts doch was in Richtung -Djava.net.useSystemProxies=true, wenn mich nicht alles täuscht). Ich muss allerdings gestehen, dass ich Maven noch nicht hinter einem Proxy verwendet habe.

npm & node.js haben auch dazu beitragen das sie Proxy Umgebungsvariablen teilweise nicht berücksichtigt haben etc.

ROFL.:

Wenn man da zu z.B. npm, yarn oder cargo schaut, dann wird man richtig neidisch.

Weiterhin gibt es regelmäßig Probleme mit dem lokalen Repository. Manche Libs funktionieren einfach nicht. Dann beginnt man in den Repos per Hand zu löschen, um zu erzwingen, das Libs oder Abhängigkeiten neu geladen werden.

Ich glaube, ich weiß was Du meinst. Wenn der Download schiefläuft, dann werden Platzhalter- und .lastUpdated-Files im Repo abgelegt. Das kann man aber leicht beheben, indem man die Abhängigkeiten aktualisiert (mvn dependency:purge-local-repository clean install, oder wenn es nur SNAPSHOTs sind mvn clean install -U). Wobei ich sagen muss: ich mach das manuell und hau im Repo den Ordner raus Dass das notwendig wurde, kann ich aber in den letzten 10+ Jahren an einer Hand abzählen. Liegt vielleicht daran, dass ich hinter keinem Proxy bin

 

[KonradN]

Mich würde da tatsächlich mehr Informationen interessieren. Gerade von @Oneixee5.

So frage ich mich gerade, ob die Probleme mit dem local Repository daran liegen können, dass es ggf. Zwischenstationen gibt, die die md5 Hash Datei und die Signierung nicht mitnehmen? Oder da es spezielle Libraries sein sollen, die öfters Probleme machen (oder habe ich das falsch verstanden?) - fehlt denen evtl. diese Dateien?

Wenn man sich z.B. https://repo1.maven.org/maven2/org/openjfx/javafx-fxml/19/ anschaut, dann sieht man ja z.B.:
javafx-fxml-19-javadoc.jar 2022-09-12 11:19 9452995
javafx-fxml-19-javadoc.jar.asc 2022-09-12 11:19 475
javafx-fxml-19-javadoc.jar.asc.md5 2022-09-12 11:19 32
javafx-fxml-19-javadoc.jar.asc.sha1 2022-09-12 11:19 40
javafx-fxml-19-javadoc.jar.md5 2022-09-12 11:19 32
javafx-fxml-19-javadoc.jar.sha1

==> Zu einer jar Datei gibt es recht viel, das die Integrität prüfen soll. Die jar Datei hat eine pgp Signatur (.asc) und zu beiden Dateien gibt es die md5 Checksumme und die sha1 Checksumme.
(Unterstützt wird von Maven md5, sha-1, sha-256 und sha-512 - https://maven.apache.org/resolver/about-checksums.html)

Damit kann Maven den Transfer verifizieren:
a) Stimmt die Signatur
b) hat der Download geklappt

Wenn diese Checks nicht durchgeführt werden können, dann gibt es natürlich eine Chance, dass die Datei korrupt ist. Wobei das ZIP format zu jeder Datei eigentlich auch eine crc32 Checksumme speichern sollte - wenn ein jar File beim Download verändert würde, dann würde das normalerweise auch auffallen.

Ansonsten findet sich noch eine weiterer Hinweis zu möglichen Problemen unter: https://maven.apache.org/resolver/local-repository.html

Shared Access to Local Repository​

In case of shared (multi-threaded, multi-process or even multi host) access to local repository, coordination is a must, as local repository is hosted on file system, and each thread may read and write concurrently into it, causing other threads or processes to get incomplete or partially written data.

Hence, since Resolver 1.7.x version, there is a pluggable API called “Named Locks” available, providing out of the box lock implementations for cases like:

• multi-threaded, in JVM locking (the default)
• multi-process locking using file system advisory locking
• multi-host locking using Hazelcast or Redisson (needs Hazelcast or Redisson cluster)

For details see Named Locks module.

Ansonsten hat sich das etwas übeschnitten mit:

Ich glaube, ich weiß was Du meinst. Wenn der Download schiefläuft, dann werden Platzhalter- und .lastUpdated-Files im Repo abgelegt. Das kann man aber leicht beheben, indem man die Abhängigkeiten aktualisiert (mvn dependency:purge-local-repository clean install, oder wenn es nur SNAPSHOTs sind mvn clean install -U). Wobei ich sagen muss: ich mach das manuell und hau im Repo den Ordner raus Dass das notwendig wurde, kann ich aber in den letzten 10+ Jahren an einer Hand abzählen. Liegt vielleicht daran, dass ich hinter keinem Proxy bin

Das mit dem -U kenne ich auch. Wenn man das nicht kennt, dann ist es nervig, da er sich merkt, dass etwas nicht herunter geladen werden konnte und er es ohne das -U nicht neu versucht. Ich erinnere mich noch gut daran, wie ich das Problem auch mal hatte ...

Das mit den Platzhalter Dateien habe ich so noch nicht beobachtet. Das dependencyurge-local-repository werde ich mir aber auch merken - man weiss ja nie, wann man sowas braucht

 

[mihe7]

Das mit den Platzhalter Dateien habe ich so noch nicht beobachtet

0 Byte große jars?

 

[KonradN]

0 Byte große jars?

Ist mir bisher nie aufgefallen, aber evtl. habe ich nie zum richtigen Zeitpunkt an der richtigen Stelle geschaut. Ich stelle das nachher einmal nach.

 

[Oneixee5]

cntlm ist nicht sehr stabil und Teil des Problems. Vermutlich wegen cntlm kam es schnell mal zum Problem mit den 0-Byte-Jar's. Bei uns funktioniert winfoom wesentlich besser - aber auch nicht immer. Im Entwicklernetz haben wir noch mal einen extra Proxy-Proxy aufgesetzt, nur für die Buildtools. Das funktioniert am Besten.
Maven sollte kaputte Downloads einfach heilen. Das kann ja nicht so schwer sein. Unverständlich sind auch Effekte, so dass jetzt alles funktioniert und am nächsten Morgen nicht mehr - wer ändert da nachts? Ich behaupte auch nicht, das Maven völlig unbrauchbar ist, aber
"mvn dependencyurge-local-repository clean install" - soll ein Witz sein oder? Wer merkt sich denn solche Zeilen? Muss ich ernsthaft noch ein Wiki mit Maven-Reparatur-Tipps anlegen? Das soll einfach funktionieren, ohne lange zu googeln und seine Arbeit machen - am Besten aus der IDE, Buildserver und CLI durch eintippen von maximal "maven build" oder "maven run". Das wäre intuitiv und angemessen. Mein Arbeitsleben besteht ja nicht daraus sich mit Maven herumzuschlagen. Da wird Zeit verbraten die gar nicht existiert und bei den ganzen anderen Baustellen fehlt. Ich brauche kein Buildsystem, welches neue Probleme macht, ich habe schon genug Andere.
Validierung ist auch kein Argument für XML, Validierung ist für viele andere Dateitypen verfügbar. Ich habe manchmal den Eindruck, dass bei Apache besonders gern XML verwendet wird, andere sind da flexibler.
Dann noch der klar definierte Lifecycle - es gibt Plugins welche einfach 2 mal in einem Build laufen. Man bekommt es entweder hin, dass sie einmal an der falschen Stelle laufen oder 2 mal und davon wenigstens einmal an der richtigen Stelle.

 

[KonradN]

Bei uns hat cntlm immer gute Dienste geleistet. Mag also ggf. an eurem generellen Setup liegen. Aber wie gesagt: Das ist kein Maven Problem.

Maven sollte kaputte Downloads einfach heilen.

Ich denke, dass die Thematik schon etwas größer ist, als Du es hier darstellst. Diese Problematik wurde sehr wohl durchdacht. Das Problem ist, dass Maven eben einen Download durchgeführt hat. Wenn Maven beim Download eben etwas bekommt das nur Länge 0 hat: Dann ist das erst einmal der Download. Wie oft soll Maven denn hier prüfen, ob es was neues gibt?

Hier kann man sich überlegen, welche Einstellung wie Sinn macht. Da man in der Regel davon ausgeht, dass die Technology stimmt und es wenig sinnvoll ist, ständig das Repository nach Updates anzufragen, wenn da z.B. eine korrupte Datei liegt, dann findet man da eine Einstellung wie z.B. eine tägliche Prüfung (das ist die default Einstellung).

Wenn man in einer besonderen Situation ist, dann macht es ggf. Sinn, dies zu verändern. Dann könnte man da z.B. always oder inzterval:nnn (nnn wären Minuten) angeben.

Maven – Settings Reference

maven.apache.org

• updatePolicy: This element specifies how often updates should attempt to occur. Maven will compare the local POM's timestamp (stored in a repository's maven-metadata file) to the remote. The choices are: always, daily (default), interval:X (where X is an integer in minutes) or never.

Die default Einstellungen passt nicht zu euren Arbeitsbedingungen? -> Dann passe die Einstellungen an!

Und dann gibt es Befehle, die man ausführen kann. Hier wäre es dann ein einfaches mvn -U package oder so.

Ich werde das bei Gelegenheit etwas austesten um zu sehen, was ich wie rekonstruieren kann. Aber im Augenblick bin ich relativ sicher, dass dieses -U Flag schon sehr genau das macht, was benötigt wird.

 

[LimDul]

Meines Erachtens liegt ein Teil des Problems nicht an Build-Tools, sondern den Firmenproxys. Wenn die noch Virenscans machen, wird das problematisch. Weil so ein Jar ja in Wirklichkeit ein ZIP ist in das man reingucken kann. Und das geht nicht immer gut aus, bzw. der Virenscanner braucht ewig...

 

[mihe7]

Das soll einfach funktionieren, ohne lange zu googeln und seine Arbeit machen - am Besten aus der IDE, Buildserver

Da hast Du völlig recht und bei mir tut das Maven auch seit weit über 10 Jahren

Es ist jedenfalls interessant, dass die Erfahrungen mal so richtig diametral verlaufen. Wir hatten die größten Probleme mit ant-Builds unter NetBeans, Maven ist da geradezu der Himmel auf Erden: keine Libs mehr in bestimmten relativen Verzeichnissen, keine NetBeans-Ant-Plugins für den Buildserver, keine NetBeans spezifischen Dateien, die einmal falsch in das Repo gepusht das komplette Projekt auf immer zerschießen.

Maven: pom.xml, das wars. Keine Abhängigkeiten von der IDE, keine Jars verwalten, so stelle ich mir das vor.

aber
"mvn dependencyurge-local-repository clean install" - soll ein Witz sein oder? Wer merkt sich denn solche Zeilen?

Keiner, wobei hier nur das dependy:purge-local-repository außergewöhnlich ist, denn:

am Besten aus der IDE, Buildserver und CLI durch eintippen von maximal "maven build" oder "maven run".

genau so ist es ja auch: mvn install - das ist alles. Will man das Projekt vorher noch säubern, macht man eben ein mvn clean install.

 

[KonradN]

genau so ist es ja auch: mvn install - das ist alles. Will man das Projekt vorher noch säubern, macht man eben ein mvn clean install.

Wobei man da ggf. Abstriche machen muss. Man hat ggf. ein Profil, das man benötigt, daher hat man dann paar Zeichen mehr:
mvn -Pprofilname install

 

[mihe7]

Wobei man da ggf. Abstriche machen muss. Man hat ggf. ein Profil, das man benötigt, daher hat man dann paar Zeichen mehr:

Sicher, aber verschiedene Konfigurationen werde ich in jedem Build-System irgendwie angeben müssen (gut, vielleicht kann man das mit OpenAI kombinieren und der TelepathyInputStream hat das auf dem Schirm, was ich gerade bauen will )

 

[KonradN]

Ja richtig, aber es ging mir hier um den Kritikpunkt der langen Kommandos, die man benötigt.

Wobei mir gerade durch den Kopf geht, dass dies eigentlich egal ist - das würde man einmal in einer Run Configuration festlegen und dann aufrufen, oder?

 

[KonradN]

Ach ja: das wäre dann die Siri / openAI Kombo:
„Computer! Übersetze das Projekt mit den notwendigen Settings um die Weltherrschaft an mich zu reißen und schick im Anschluss Pinky & TheBrain eine Email: „erster!“

 

[mihe7]

Wobei mir gerade durch den Kopf geht, dass dies eigentlich egal ist - das würde man einmal in einer Run Configuration festlegen und dann aufrufen, oder?

In der IDE sowieso und bei Jenkins trägt man das ja auch in das Script ein. Einzig, wenn man es wirklich über die Konsole eintippen will, muss man wirklich etwas mehr tippen.

Ich verstehe @Oneixee5 aber durchaus: wenn mir ein Buildsystem ständig Steine in den Weg legt, dann macht das keinen Spaß. Ich hatte bislang einfach Glück und musste die Erfahrung bei Maven noch nicht machen. Bei uns war Maven die Lösung für ant und bei @Oneixee5 scheint es gerade andersrum zu sein. Das ist schon irgendwie interessant.

 

[LimDul]

Das Problem sind auch nicht die Build-Systeme sondern die komplexen Builds und Anwendungen in Kombination mit Infrastruktur-Herausforderungen.

Meine Maven Kommandozeile ist lang, weil ich:

• tests überspringe
• spotbugs überspringe
• checkstyle überspringe
• parallel baue

Ansonsten dauert der Build viel zu lange. Maven ist hier aber nicht das Problem, sondern unser riesiger Monolith mit 46 Maven Modulen, 750k Lines of Code und entsprechender Zahl an Unit Tests.

 

[Oneixee5]

Bei uns war Maven die Lösung für ant und bei @Oneixee5 scheint es gerade andersrum zu sein. Das ist schon irgendwie interessant.

Mit Apache Ant + Ivy habe ich eigentlich immer gern gearbeitet. Bei kleinen Projekten hat die Kombination immer sehr gut funktioniert und der Aufwand war gering. Erstaunlicherweise gibt es mit Ant/Ivy die Proxyprobleme überhaupt nicht. Selber Hersteller wie Maven! Mit der Einführung von Softwarestücklisten wurde Maven inkl. bestimmter Plugins aber vorgeschrieben. Damit haben sich natürlich dann einige Probleme noch auf weitere Projekte ausgedehnt. Es gab aber auch mal eine Zeit, da funktionierte Maven sehr stabil und ich war optimistisch, dass jetzt alles gut ist. Nur leider gehen auch die guten Zeiten mal zu Ende

 

[mihe7]

Meine Maven Kommandozeile ist lang, weil ich:

Bei uns läuft das so, dass wir für Jenkins ein Profil haben, das vollständig durchläuft und zusätzlich z. B. die Versionsnummer im .properties-File setzt. Während der Entwicklung überspringe ich Tests in der Regel auch, da sind die entsprechenden Maven-Flags dann einfach in der IDE konfiguriert. Wenn ich irgendwas bestimmtes will, rufe ich über die IDE das entsprechende Goal auf. Mittlerweile verwende ich Maven auch für z. B. Asciidoc-Projekte Knöpfchen drücken, HTML- und/oder PDF-Ausgabe im target-Verzeichnis. Saubere Verzeichnisstruktur, ein pom, rein ins git, hervorragend.

 

[LimDul]

Kommst du vorbei und bringst das auch in meiner Eclipse IDE ans Laufen.

Randbedingungen:

• Eclipse
• JBoss
• Vaadin 23
• Keinen Einfluss auf den Jenkins

Sprich, da hängt Node.js und npm und viel viel lustiges Zeug dran. Das Bitte in Eclipse ans laufen bringen, dass ich in Eclipse zuverlässig auf den Jboss deployen kann

 

[Oneixee5]

Kommst du vorbei und bringst das auch in meiner Eclipse IDE ans Laufen.

Randbedingungen:

• Eclipse
• JBoss
• Vaadin 23
• Keinen Einfluss auf den Jenkins

Sprich, da hängt Node.js und npm und viel viel lustiges Zeug dran. Das Bitte in Eclipse ans laufen bringen, dass ich in Eclipse zuverlässig auf den Jboss deployen kann

Viel Spaß!

 

[mihe7]

Eclipse IDE

Auch mit Maven gibt es Grenzen des Machbaren

 

[KonradN]

Kommst du vorbei und bringst das auch in meiner Eclipse IDE ans Laufen.

Randbedingungen:

• Eclipse
• JBoss
• Vaadin 23
• Keinen Einfluss auf den Jenkins

Sprich, da hängt Node.js und npm und viel viel lustiges Zeug dran. Das Bitte in Eclipse ans laufen bringen, dass ich in Eclipse zuverlässig auf den Jboss deployen kann

Das muss man im Detail anschauen. Auch in Eclipse kannst Du ja mit den Run Configurations sehr viel machen. Manuell kriegst du es ja offenbar hin. Aber die Liste zeigt es ja auch: Das ist offenbar kein Maven Problem sondern en Eclipse / JBoss / Vaadin23 / Jenkins Problem ....

Mit Maven habe ich schon einiges gemacht und ich habe da auch teilweise in der Vergangenheit irgendwelche speziellen Plugins rausgeschmissen und einfach das Maven Exec Plugin genutzt für paar Aufrufe.

Zur Not muss ein eigenes Maven Plugin her (Etwas auf meiner TODO Liste, aber sehr weit unten).

 

[LimDul]

Ja, Maven ist da das geringste Problem. Das ganze zusammenspiel der Maven Plugins in Eclipse, Deployment des exploded wars, Build mit NPM für das Vaadin Frontend funktioniert in Eclipse "manchmal". Dementsprechend baue ich auf der Kommandozeile und deploye das gebaute WAR einfach. Das funktioniert, ein Build (ohne clean) dauert ca. 3 Minuten, das ist "ok".

 

[mihe7]

Dementsprechend baue ich auf der Kommandozeile und deploye das gebaute WAR einfach.

Was ich unter NB 15 verwendet habe (weil Payara 6 nicht unterstützt wurde), war https://github.com/AdamBien/wad - das Tool führt bei Änderung an den Quelltexten halt einen Maven Build aus und kopiert das WAR in ein konfiguriertes Directory fürs Autodeployment. Ist natürlich nur eine kleine Erleichterung ggü. dem in NB integrierten Deployment, aber besser als nix. Da OpenSource sollte das ja leicht anpassbar sein.

 

[DaBe1812]

Hi,
schön dass ihr so abgeschweift seid und das ganze irgendwie in ein Maven-Thema gewandelt wurde.

Ich habe aber zum ursprünglichen Thema noch eine Frage:

Der java.net HttpClient funktioniert erstmal ganz gut, bis auf eine Ausnahme.
Ich habe ein Fremdsystem, das liefert, wenn es das angefragte System nicht kennt ein HTTP204.

Mit dem ApacheHttpClient kam eine Response und die hatte den Statuscode 204.

java.net sieht das ganze irgendwie anders und droppt eine Exception:

java.io.IOException: unexpected content length header with 204 response
    at jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:565) ~[java.net.http:?]
    at jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:119) ~[java.net.http:?]
    at main.java.refSystems.utils.httpClientManager.AtcClientBuilder.executeHttpRequest(AtcClientBuilder.java:172) [classes/:?]
    at main.java.refSystems.fii.FiiRestController.searchSingle(FiiRestController.java:81) [classes/:?]
    at main.java.refSystems.fii.FiiRestController.search(FiiRestController.java:66) [classes/:?]
    at main.java.refSystems.fii.FiiFunctions.searchElements(FiiFunctions.java:48) [classes/:?]
    at jdk.internal.reflect.GeneratedMethodAccessor1318.invoke(Unknown Source) ~[?:?]
    at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
    at com.ibm.ejs.container.EJSContainer.invokeProceed(EJSContainer.java:4886) [com.ibm.ws.ejbcontainer_1.0.64.jar:?]
    at [internal classes]
    at jdk.internal.reflect.GeneratedMethodAccessor1073.invoke(Unknown Source) ~[?:?]
    at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
    at com.ibm.ejs.container.interceptors.InterceptorProxy.invokeInterceptor(InterceptorProxy.java:189) [com.ibm.ws.ejbcontainer_1.0.64.jar:?]
    at [internal classes]
    at jdk.internal.reflect.GeneratedMethodAccessor1072.invoke(Unknown Source) ~[?:?]
    at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
    at com.ibm.ejs.container.interceptors.InterceptorProxy.invokeInterceptor(InterceptorProxy.java:189) [com.ibm.ws.ejbcontainer_1.0.64.jar:?]
    at [internal classes]
    at main.java.atc.interfaces.EJSLocal0SLFiiFunctions_60a873bd.searchElements(EJSLocal0SLFiiFunctions_60a873bd.java) [?:?]
    at jdk.internal.reflect.GeneratedMethodAccessor1317.invoke(Unknown Source) ~[?:?]
    at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
    at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:410) [com.ibm.ws.org.jboss.weld3_1.0.64.jar:3.1.8.Final]
    at [internal classes]
    at main.java.atc.interfaces.ReferenceController$712004753$Proxy$_$$_Weld$EnterpriseProxy$.searchElements(Unknown Source) [classes/:?]
    at main.java.atc.executors.SearchExecutor.searchController(SearchExecutor.java:98) [classes/:?]
    at main.java.atc.executors.SearchExecutor.lambda$createTasks$0(SearchExecutor.java:87) [classes/:?]
    at main.java.atc.executors.SearchExecutor$$Lambda$477/0x00000000440615c0.call(Unknown Source) [classes/:?]
    at com.ibm.ws.threading.internal.PolicyTaskFutureImpl.run(PolicyTaskFutureImpl.java:714) [com.ibm.ws.threading_1.1.64.jar:?]
    at [internal classes]
    at main.java.atc.executors.SearchExecutor.doSearch(SearchExecutor.java:50) [classes/:?]
    at main.java.atc.executors.SearchExecutor$Proxy$_$$_WeldClientProxy.doSearch(Unknown Source) [classes/:?]
    at main.java.handler.SearchHandler.search(SearchHandler.java:112) [classes/:?]
    at jdk.internal.reflect.GeneratedMethodAccessor1303.invoke(Unknown Source) ~[?:?]
    at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
    at org.apache.el.parser.AstValue.invoke(AstValue.java:245) [com.ibm.ws.org.apache.jasper.el.3.0_3.0.64.jar:?]
    at [internal classes]
    at javax.faces.event.MethodExpressionActionListener.processAction(MethodExpressionActionListener.java:83) [com.ibm.websphere.javaee.jsf.2.3_1.0.64.jar:2.3.9]
    at javax.faces.event.ActionEvent.processListener(ActionEvent.java:58) [com.ibm.websphere.javaee.jsf.2.3_1.0.64.jar:2.3.9]
    at javax.faces.component.UIComponentBase.broadcast(UIComponentBase.java:429) [com.ibm.websphere.javaee.jsf.2.3_1.0.64.jar:2.3.9]
    at javax.faces.component.UICommand.broadcast(UICommand.java:103) [com.ibm.websphere.javaee.jsf.2.3_1.0.64.jar:2.3.9]
    at javax.faces.component.UIViewRoot._broadcastAll(UIViewRoot.java:1255) [com.ibm.websphere.javaee.jsf.2.3_1.0.64.jar:2.3.9]
    at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:420) [com.ibm.websphere.javaee.jsf.2.3_1.0.64.jar:2.3.9]
    at javax.faces.component.UIViewRoot._process(UIViewRoot.java:1741) [com.ibm.websphere.javaee.jsf.2.3_1.0.64.jar:2.3.9]
    at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:935) [com.ibm.websphere.javaee.jsf.2.3_1.0.64.jar:2.3.9]
    at org.apache.myfaces.lifecycle.InvokeApplicationExecutor.execute(InvokeApplicationExecutor.java:42) [com.ibm.ws.org.apache.myfaces.2.3_1.0.64.jar:2.3.9]
    at [internal classes]
    at javax.faces.webapp.FacesServlet.service(FacesServlet.java:204) [com.ibm.websphere.javaee.jsf.2.3_1.0.64.jar:2.3.9]
    at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1258) [com.ibm.ws.webcontainer_1.1.64.jar:?]
    at [internal classes]
    at com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilter

Die Zeilen, die dazu führen könnten theoretisch auch interessant sein:

HttpRequest request = requestBuilder.build();
HttpClient client = HttpClient.newHttpClient();
HttpResponse<String> response = client.send(request, BodyHandlers.ofString());
int statusCode = response.statusCode();

Droppen tut der Fehler bei client.send, also in die letzte Zeile komm ich garnicht.

 

[LimDul]

[JDK-8214692] HttpClient throws IOException: unexpected content length header with 204 response - Java Bug System

bugs.openjdk.org

Wenn ich den Bug Report richtig lese, verhält sich der Server nicht standardkonform gemäß dem RFC und der Java Client sagt dann "Bäm, Exception". Sprich, Oracle stellt sich da auf den Standpunkt "Nicht unser Problem..."

 

[DaBe1812]

Hi,
das war nach allem, was ich so geggogelt habe auch meine Befürchtung. Also bleibt mir aktuell nichts anderes als die Exception zu fangen, zu prüfen, ob da irgendwo 204 steht und dann halt so zu tun, als hätte es die Exception nie gegeben.

 

[DaBe1812]

Und direkt der nächste Supergau, wenn ich den nicht gelöst bekomme, muss ich zurück zum ApacheClient:
Ich habe jetzt im letzten Fremdsystem beim Testen einen SSL-Fehler. Im ApacheClient wird auch eine SSLException geworfen.
Aber im java.net kommt:

java.io.IOException: HTTP/1.1 header parser received no bytes
    at jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:565) ~[java.net.http:?]
    at jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:119) ~[java.net.http:?]
    at main.java.refSystems.utils.httpClientManager.AtcClientBuilder.executeHttpRequest(AtcClientBuilder.java:173) [classes/:?]
    at main.java.refSystems.am.AmRestController.isAvailable(AmRestController.java:37) [classes/:?]
    at main.java.refSystems.am.AmFunctions.isAvailable(AmFunctions.java:104) [classes/:?]
    at jdk.internal.reflect.GeneratedMethodAccessor1223.invoke(Unknown Source) ~[?:?]
    at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
    at com.ibm.ejs.container.EJSContainer.invokeProceed(EJSContainer.java:4886) [com.ibm.ws.ejbcontainer_1.0.64.jar:?]
    at [internal classes]
    at jdk.internal.reflect.GeneratedMethodAccessor1059.invoke(Unknown Source) ~[?:?]
    at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
    at com.ibm.ejs.container.interceptors.InterceptorProxy.invokeInterceptor(InterceptorProxy.java:189) [com.ibm.ws.ejbcontainer_1.0.64.jar:?]
    at [internal classes]
    at jdk.internal.reflect.GeneratedMethodAccessor1058.invoke(Unknown Source) ~[?:?]
    at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
    at com.ibm.ejs.container.interceptors.InterceptorProxy.invokeInterceptor(InterceptorProxy.java:189) [com.ibm.ws.ejbcontainer_1.0.64.jar:?]
    at [internal classes]
    at main.java.atc.interfaces.EJSLocal0SLAmFunctions_c0ad3b68.isAvailable(EJSLocal0SLAmFunctions_c0ad3b68.java) [?:?]
    at jdk.internal.reflect.GeneratedMethodAccessor1222.invoke(Unknown Source) ~[?:?]
    at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
    at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:410) [com.ibm.ws.org.jboss.weld3_1.0.64.jar:3.1.8.Final]
    at [internal classes]
    at main.java.atc.interfaces.ReferenceController$793883809$Proxy$_$$_Weld$EnterpriseProxy$.isAvailable(Unknown Source) [classes/:?]
    at main.java.timer.AvailableInterface.checkController(AvailableInterface.java:78) [classes/:?]
    at main.java.timer.AvailableInterface.lambda$createTasks$0(AvailableInterface.java:68) [classes/:?]
    at main.java.timer.AvailableInterface$$Lambda$472/0x000000001d1ea020.call(Unknown Source) [classes/:?]
    at com.ibm.ws.threading.internal.PolicyTaskFutureImpl.run(PolicyTaskFutureImpl.java:714) [com.ibm.ws.threading_1.1.64.jar:?]
    at [internal classes]
    at main.java.timer.AvailableInterface.checkAllSystems(AvailableInterface.java:46) [classes/:?]
    at main.java.timer.AvailableInterface$Proxy$_$$_WeldClientProxy.checkAllSystems(Unknown Source) [classes/:?]
    at main.java.handler.StatusHandler.refreshParameter(StatusHandler.java:38) [classes/:?]
    at jdk.internal.reflect.GeneratedMethodAccessor1208.invoke(Unknown Source) ~[?:?]
    at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
    at org.apache.el.parser.AstValue.invoke(AstValue.java:245) [com.ibm.ws.org.apache.jasper.el.3.0_3.0.64.jar:?]
    at [internal classes]
    at javax.faces.event.MethodExpressionActionListener.processAction(MethodExpressionActionListener.java:83) [com.ibm.websphere.javaee.jsf.2.3_1.0.64.jar:2.3.9]
    at javax.faces.event.ActionEvent.processListener(ActionEvent.java:58) [com.ibm.websphere.javaee.jsf.2.3_1.0.64.jar:2.3.9]
    at javax.faces.component.UIComponentBase.broadcast(UIComponentBase.java:429) [com.ibm.websphere.javaee.jsf.2.3_1.0.64.jar:2.3.9]
    at javax.faces.component.UICommand.broadcast(UICommand.java:103) [com.ibm.websphere.javaee.jsf.2.3_1.0.64.jar:2.3.9]
    at javax.faces.component.UIViewRoot._broadcastAll(UIViewRoot.java:1255) [com.ibm.websphere.javaee.jsf.2.3_1.0.64.jar:2.3.9]
    at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:420) [com.ibm.websphere.javaee.jsf.2.3_1.0.64.jar:2.3.9]
    at javax.faces.component.UIViewRoot._process(UIViewRoot.java:1741) [com.ibm.websphere.javaee.jsf.2.3_1.0.64.jar:2.3.9]
    at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:935) [com.ibm.websphere.javaee.jsf.2.3_1.0.64.jar:2.3.9]
    at org.apache.myfaces.lifecycle.InvokeApplicationExecutor.execute(InvokeApplicationExecutor.java:42) [com.ibm.ws.org.apache.myfaces.2.3_1.0.64.jar:2.3.9]
    at [internal classes]
    at javax.faces.webapp.FacesServlet.service(FacesServlet.java:204) [com.ibm.websphere.javaee.jsf.2.3_1.0.64.jar:2.3.9]
    at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1258) [com.ibm.ws.webcontainer_1.1.64.jar:?]
    at [internal classes]
    at com.ibm.ws.webcontainer.filter.We
bAppFilterManager.invokeFilters(WebAppFilterManager.java:1011) [com.ibm.ws.webcontainer_1.1.64.jar:?]
    at com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:75) [com.ibm.ws.webcontainer_1.1.64.jar:?]
    at [internal classes]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
    at java.lang.Thread.run(Thread.java:836) [?:?]
Caused by: java.io.IOException: HTTP/1.1 header parser received no bytes
    at jdk.internal.net.http.common.Utils.wrapWithExtraDetail(Utils.java:303) ~[java.net.http:?]
    at jdk.internal.net.http.Http1Response$HeadersReader.onReadError(Http1Response.java:665) ~[java.net.http:?]
    at jdk.internal.net.http.Http1AsyncReceiver.checkForErrors(Http1AsyncReceiver.java:297) ~[java.net.http:?]
    at jdk.internal.net.http.Http1AsyncReceiver.flush(Http1AsyncReceiver.java:263) ~[java.net.http:?]
    at jdk.internal.net.http.Http1AsyncReceiver$$Lambda$536/0x000000001adc1f40.run(Unknown Source) ~[?:?]
    at jdk.internal.net.http.common.SequentialScheduler$SynchronizedRestartableTask.run(SequentialScheduler.java:175) ~[java.net.http:?]
    at jdk.internal.net.http.common.SequentialScheduler$CompleteRestartableTask.run(SequentialScheduler.java:147) ~[java.net.http:?]
    at jdk.internal.net.http.common.SequentialScheduler$SchedulableTask.run(SequentialScheduler.java:198) ~[java.net.http:?]
    ... 3 more
Caused by: java.io.IOException: Eine vorhandene Verbindung wurde vom Remotehost geschlossen
    at sun.nio.ch.SocketDispatcher.read0(Native Method) ~[?:?]
    at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:43) ~[?:?]
    at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:276) ~[?:?]
    at sun.nio.ch.IOUtil.read(IOUtil.java:233) ~[?:?]
    at sun.nio.ch.IOUtil.read(IOUtil.java:223) ~[?:?]
    at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:356) ~[?:?]
    at jdk.internal.net.http.SocketTube.readAvailable(SocketTube.java:1153) ~[java.net.http:?]
    at jdk.internal.net.http.SocketTube$InternalReadPublisher$InternalReadSubscription.read(SocketTube.java:821) ~[java.net.http:?]
    at jdk.internal.net.http.SocketTube$InternalReadPublisher$InternalReadSubscription$$Lambda$528/0x000000001d1ad040.run(Unknown Source) ~[?:?]
    at jdk.internal.net.http.SocketTube$SocketFlowTask.run(SocketTube.java:175) ~[java.net.http:?]
    at jdk.internal.net.http.common.SequentialScheduler$SchedulableTask.run(SequentialScheduler.java:198) ~[java.net.http:?]
    at jdk.internal.net.http.common.SequentialScheduler.runOrSchedule(SequentialScheduler.java:271) ~[java.net.http:?]
    at jdk.internal.net.http.common.SequentialScheduler.runOrSchedule(SequentialScheduler.java:224) ~[java.net.http:?]
    at jdk.internal.net.http.SocketTube$InternalReadPublisher$InternalReadSubscription.signalReadable(SocketTube.java:763) ~[java.net.http:?]
    at jdk.internal.net.http.SocketTube$InternalReadPublisher$ReadEvent.signalEvent(SocketTube.java:941) ~[java.net.http:?]
    at jdk.internal.net.http.SocketTube$SocketFlowEvent.handle(SocketTube.java:245) ~[java.net.http:?]
    at jdk.internal.net.http.HttpClientImpl$SelectorManager.handleEvent(HttpClientImpl.java:957) ~[java.net.http:?]
    at jdk.internal.net.http.HttpClientImpl$SelectorManager.lambda$run$3(HttpClientImpl.java:912) ~[java.net.http:?]
    at jdk.internal.net.http.HttpClientImpl$SelectorManager$$Lambda$553/0x000000001d1b6730.accept(Unknown Source) ~[?:?]
    at java.util.ArrayList.forEach(ArrayList.java:1541) ~[?:?]
    at jdk.internal.net.http.HttpClientImpl$SelectorManager.run(HttpClientImpl.java:912) ~[java.net.http:?]

Also, da wir hier ab und an mal SSL-Probleme haben, weil wieder jemand seinen Server ändert und meint, er könnte sich mal schnell ein Selfsigned Certificate geben, weil beim lokalen Test klappt ja alles, wäre es mir schon sehr wichtig, dass ich SSL-Fehler auch erkennen kann.

Mach ich da noch was falsch?

Die anderen Systeme sind teilweise SSL und funktionieren. Hier liegt es klar am anderen Server, aber ich würde halt auch gerne in der Fehlermeldung sehen, woran.

 

[mihe7]

Hier liegt es klar am anderen Server, aber ich würde halt auch gerne in der Fehlermeldung sehen, woran.

Steht da:

java.io.IOException: HTTP/1.1 header parser received no bytes

Standardmäßig wird eine HTTP/2-Verbindung aufgebaut, der Server erwartet offensichtlich eine HTTP/1.1-Verbindung. Versuch mal, die Version 1.1 anzugeben:

HttpClient client = HttpClient.newBuilder()
        .version(Version.HTTP_1_1)
        .build();

(s. dazu auch das Beispiel in https://docs.oracle.com/en/java/javase/19/docs/api/java.net.http/java/net/http/HttpClient.html)

 

[DaBe1812]

Hi,

ich glaube das habe ich eigentlich schon gesetzt:

public JSONObject executeHttpRequest(String url, String payload, boolean isAddition, boolean withAuthHeader, RequestType type) {

        URI uri = null;
        JSONObject result = new JSONObject();
        
        try {
            if(isAddition) {
                uri = new URI(BASE_URL + url);
            } else {
                uri = new URI(url);
            }
            
            Builder requestBuilder = HttpRequest.newBuilder();
            
            requestBuilder.uri(uri);
            requestBuilder.header("Accept", "application/json");
            requestBuilder.version(Version.HTTP_1_1);
            
            for (String key : headers.keySet()) {
                requestBuilder.header(key, headers.get(key));
            }

            if(withAuthHeader) {
                String authHeader = getAuth();
                requestBuilder.header("Authorization", authHeader);
            }

            switch(type) {
            case DELETE:
                requestBuilder.DELETE();
                break;
            case GET:
                requestBuilder.GET();
                break;
            case POST:
                requestBuilder.header("Content-Type", "application/json");
                requestBuilder.POST(HttpRequest.BodyPublishers.ofString(payload));
                break;
            }
            
            HttpRequest request = requestBuilder.build();

            HttpClient client = HttpClient.newHttpClient();
            HttpResponse<String> response = client.send(request, BodyHandlers.ofString());

            int statusCode = response.statusCode();

            if (statusCode == 200) {
                String body = response.body();
                if(body != null && !"".equals(body)) {
                    if(body.substring(0, 1).equals("[")) {
                        JSONArray tempArr = new JSONArray(body);
                        result = tempArr.getJSONObject(0);
                    } else {
                        result = new JSONObject(response.body());
                    }
                } else {
                    result = new JSONObject();
                    result.put("result", 200);
                }
            } else if (statusCode == 204
                    || statusCode == 503) {
                return null;
            } else {
                JSONObject content = null;
                String detail = null;
                try {
                    content = new JSONObject(response.body());
                } catch (Exception e){}
                if(content != null) {
                    if(content.has("error")) {
                        detail = content.getJSONObject("error").getString("detail");
                    }
                    
                }
                result.put("error", "HTTPCode: " + statusCode);
                if(detail != null) {
                    result.put("detail", detail);
                }
            }

        } catch (SSLException e) {
            LOG.error("SSL Fehler beim Aufruf " + REFERENCESYSTEM.displayName());
            result.put("error", "SSL Fehler beim Aufruf");
        } catch (IOException | InterruptedException | URISyntaxException e) {
            if(REFERENCESYSTEM == ReferenceSystem.FII) {
                String message = e.getMessage();
                if(message.contains("204")) {
                    return null;
                }
                LOG.info(e.getMessage());
            }
            LOG.error("Fehler beim HTTPGet für " + REFERENCESYSTEM.displayName() + " ", e);
            result.put("error", e.getMessage());
        }
        return result;
}

Kam aber zum selben Problem.

 

[mihe7]

Dann musst Du etwas Debugging betreiben, z. B. kannst Du mal das ganze Netzwerkzeug loggen, ruf die Anwendung mal mit -Djavax.net.debug=all auf.

 

[DaBe1812]

Tja, hat sich leider erledigt. Das andere System arbeitet wieder einwandfrei.