Ich bin großer Fan von Reflection (Hallo, Johann 👋). Aber einige Sachen sind gar nicht soo offensichtlich hinzubekommen, etwa das Finden aller Sub-Klassen. Doch grämet euch nicht, es gibt Reflections:
|
1 2 3 4 |
Reflections reflections = new Reflections("net.crusy.foo"); for (Class<?> subClass : reflections.getSubTypesOf(SomeInterface.class)) { // do stuff } |
Den Typ eines Parameters prüft man so:
|
1 |
verify(myMock).myMethod(isA(MyType.class)); |
Aber was, wenn man auf einen bestimmten Übergabeparameter und dessen parametrisierten Typ prüfen will?
|
1 2 3 4 5 6 7 8 9 10 11 12 |
// given @SuppressWarnings("unchecked") Class<List<MyType>> parameterizedClass = (Class<List<MyType>>) (Class) List.class; ArgumentCaptor<List<MyType>> argument = ArgumentCaptor.forClass(parameterizedClass); // when: myInstance.onServerEvent(..) is called myInstance.onServerEvent(someServerEvent()); // then: myMock.myMethod(..) is called with a list of MyType verify(myMock, times(1)).myMethod(argument.capture()); assertTrue(argument.getValue().size() == 1); assertTrue(argument.getValue().get(0) instanceof MyType); // might be redundant |
Das ist tatsächlich nicht so trivial, aber der Reihe nach:
Wer danach googelt, findet erstaunlich (?) häufig den Ansatz, die URL auf endsWith(“.pdf”) zu prüfen 😳 Das sagt natürlich nichts darüber, ob das PDF auch dargestellt wird (oder ob es das richtige PDF ist), aber als erste Näherung habe ich das übernommen. Allerdings prüfe ich die URL etwas genauer, und vergleiche sie mit der URL, deren PDF-Ausgabe backendseitig bereits inhaltlich geprüft wird:
|
1 2 |
String expected = getBaseUrl() + "item/[0-9]+/print" url.matches(expected) |
Kurz hatte ich dann überlegt, auf den Content Type zu prüfen, aber da kann natürlich alles drin stehen. Die o.g. Bedingungen stellt das ebenfalls nicht sicher.
Dann gibt es Ansätze, STRG+A/STRG+C zu nutzen (Beispiel), um den Inhalt des PDF zu verifizieren – funktioniert nicht mit jedem OS/Browser.
Dann, ebenfalls häufig genannt: PDFBox. Finde ich gut, so kommt man an den Inhalt des PDFs und kann sicherstellen, dass es das richtige PDF ist:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
import org.apache.commons.codec.binary.Base64 import org.apache.pdfbox.pdmodel.PDDocument import org.apache.pdfbox.text.PDFTextStripper // test if there's a PDF at this URI: PDDocument pdf = getAsPDF(url) noExceptionThrown() pdf != null // and if the PDF seems to be valid: String text = extractTextFromPDF(pdf) text.contains("foo bar") // ... mit: PDDocument getAsPDF(String theUrl) throws Exception { // bonus points: The end point needs authentification :-) byte[] credentials = new Base64().encode("admin:admin".getBytes()) String basicAuth = "Basic " + new String(credentials) URL url = new URL(theUrl) URLConnection uc = url.openConnection() uc.setRequestProperty("Authorization", basicAuth) PDDocument.load(uc.getInputStream()) } String extractTextFromPDF(PDDocument pdf) { PDFTextStripper pdfStripper = new PDFTextStripper() pdfStripper.setStartPage(1) // 1-based pdfStripper.setEndPage(pdf.getPages().count) // inclusive pdfStripper.getText(pdf) } |
Nachteil: Dass die URL [ein|das richtige] PDF ausliefert, sagt natürlich nichts darüber, dass das im Browser dargestellt wird 🙃
Also: Screenshot machen. Allerdings nicht die Selenium-Methode, denn aus Browser-Sicht ist die Seite “leer”, das PDF wird von einem Plugin gerendert. Die Lösung dazu: Robot.
ACHTUNG: Das geht nicht in einer “headless”-Umgebung, wie man sie bsplw. auf vielen CI-Servern findet:
java.awt.AWTException: headless environment
Mit einem waitFor, bis das PDF tatsächlich gerendert wurde (denn das ist ungleich “die Seite wurde geladen”):
|
1 2 3 4 5 6 |
BufferedImage screenshot = null waitFor { screenshot = getScreenshot(driver) !new Color(screenshot.getRGB(100, 100)).equals(Color.white) } |
und einem kleinen Trick, um statt des Bildschirms nur den Browserinhalt zu screenshoten:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
static Rectangle getWindowRectangle(WebDriver driver) { WebDriver.Window window = driver.manage().window() new Rectangle( window.position.x, window.position.y, window.size.width, window.size.height ) } /** * Works with PDF etc as well. */ static BufferedImage getScreenshot(WebDriver driver) { new Robot().createScreenCapture(getWindowRectangle(driver)); } |
Auf Basis des Bildes kann man nun sicherstellen, dass keine weiße Seite gerendert wurde…
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
boolean foundRefColor1 = false boolean foundRefColor2 = false for (int x = 0; x < screenshot.width; x++) { for (int y = 0; y < screenshot.height; y++) { Color current = new Color(screenshot.getRGB(x, y)) if (!foundRefColor1 && current.equals(COLOR_1)) { foundRefColor1 = true break } else if (!foundRefColor2 && current.equals(COLOR_2)) { foundRefColor2 = true break } } if (foundRefColor1 && foundRefColor2) { break } } foundRefColor1 && foundRefColor2 |
…oder halt irgendwas. Man könnte auch PNG-Vergleiche machen. Inhaltlich, wie gesagt, würde man mit PDFBox testen, darum ging es hier aber nicht.
HTH.
Problem: Wie kann ich einen resources-Ordner durchsuchen – in der IDE, im .jar und aus jUnit-Test heraus1?
Lösung: PathMatchingResourcePatternResolver.getResources(String locationPattern)
Beispiel:
|
1 2 3 |
PathMatchingResourcePatternResolver resolver = new PathMatchingResourcePatternResolver(); Resource[] resources = resolver.getResources("classpath*:**/definitions/*.def"); // resources may contain "duplicates"=copies from different locations |
1Wo getClass().getResource(MY_FOLDER + "someFile.def"); funktioniert, aber getClass().getResource(MY_FOLDER); nicht2.
2wtf.
Vorab: Ja, es gibt @RequestBody. Und es ist hässlich. Ich habe es nicht mal eingebaut. Aber ich musste es googlen und will das nicht noch mal tun müssen:
|
1 2 3 4 5 6 7 8 9 10 |
private Long extractFooBarFromRequest() { if ("POST".equalsIgnoreCase(request.getMethod())) { try { String jsonString = CharStreams.toString(request.getReader()); JsonObject jsonObject = new JsonParser().parse(jsonString).getAsJsonObject(); return jsonObject.get("fooBar").getAsLong(); } catch (Exception ignore) {} } return null; } |
PS zu Zeile 2 und zu Zeile 4.
Listen:
|
1 |
List<String> emptyList = new ArrayList<>(); |
Sie können “einzeilig” initialisiert werden:
|
1 2 3 4 5 6 7 8 9 10 |
ArrayList<String> nichtWirklichEinzeilig = new ArrayList<String>() {{ add("A"); add("B"); add("C"); }}; List<String> immutableList1 = Arrays.asList("A", "B", "C"); List<String> immutableList2 = Collections.singletonList("A"); ArrayList<String> mutableList = new ArrayList<>(Arrays.asList("A", "B", "C")); |
Aber: Was, wenn ich sie mit anonymen Klassen initialisieren will?
|
1 2 3 4 5 6 7 |
// DOESN'T WORK! List<Foo> doesntWork = Arrays.asList(new Foo() { @Override public String bar() { return "Hello moto"; } }); |
Geht nicht, weil die anonyme Klasse Foo beerbt, und damit kommt Java nicht klar. Aber
|
1 2 3 4 5 6 |
List<Foo> fooList = Arrays.asList(new Foo[]{new Foo() { @Override public String bar() { return "Hello moto"; } }}); |
geht. Hässlich, aber es geht. 🙂 Ein bisschen schöner (weil lesbarer) geht es mit Guava, aber im Grunde ist das genauso umständlich:
|
1 2 3 4 5 6 |
List<Foo> fooList = FluentIterable.of(new Foo[]{}).append(new Foo() { @Override public String bar() { return "Hello moto"; } }).toList(); |
Weitere Vorschläge?
Googelt man “open file” etc., geht es meistens darum, eine Datei einzulesen. In meinem konkreten Fall wollte ich sie aber öffnen, also bsplw. ein PDF im Reader. Lösung:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
import java.awt.Desktop; import java.nio.file.Path; import java.nio.file.Paths; // ... Path path = Paths.get(System.getProperty("java.io.tmpdir"), "report.pdf"); // ... if (Desktop.isDesktopSupported()) { Desktop desktop = Desktop.getDesktop(); if (desktop.isSupported(Desktop.Action.OPEN)) { desktop.open(path.toFile()); } } |
Achtung: Eventuelle Handles müssen geschlossen werden, oder es gibt ein
There was an error opening this document. This file is already open or in use by another application.
Für einen OutputStream sieht das so aus:
|
1 2 3 4 5 6 7 8 9 |
OutputStream out; try { out = Files.newOutputStream(path); joinedReport.writeTo(out); } finally { if(null != out) { out.close(); } } |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
// create a single Jar with all dependencies // (avoids "no main manifest attribute, in HelloWorld-1.0.jar") task fatJar(type: Jar) { manifest { attributes 'Implementation-Title': 'Hello World', 'Implementation-Version': version, 'Main-Class': 'net.crusy.java.HelloWorld' } baseName = project.name + '-all' from { configurations.compile.collect { it.isDirectory() ? it : zipTree(it) } } exclude 'META-INF/*.RSA', 'META-INF/*.SF','META-INF/*.DSA' with jar } |
Quelle, ergänzt um, Aufruf dann via
|
1 2 3 |
$ gradle clean $ gradle fatJar $ java -jar .\build\libs\HelloWorld-all-1.0.jar |
|
1 |
@PreAuthorize("hasAuthority('FOOBAR') and isFullyAuthenticated()") |
ist stellenweise verwirrend beschrieben. Hier heißt es
Returns
trueif the user is not an anonymous or a remember-me user
, wobei die Klammerung fehlt: “not” bezieht sich auf beides! Hier ist es IMHO auf andere Art verwirrend, aber zumindest nicht mehrdeutig:
Determines if theSecurityExpressionOperations.getAuthentication()authenticated without the use of remember me
Neulich™ hatte ich das Problem, dass ein UTF-8-enthaltender String falsch nach XML transformiert wurde. UTF-8 ist (? war es zumindest früher oft) so eine Sache in Java, man muss(te) an drölf Stellen das Encoding explizit setzen; dazu gehörten zB Stream, Writer/Reader, StringBuilder, etc pp. Das mag inzwischen anders sein, denn nach langem Debugging stellte sich raus, dass nur das File-Encoding in IntelliJ falsch gesetzt war – der Code funkionierte ohne Änderung, die Quelle des Strings war bereits fehlerhaft gespeichert. Irreführenderweise hatte der IntelliJ-Debugger den String die ganze Kette hindurch korrekt angezeigt. “Nimm IntelliJ” haben sie gesagt, “das funktioniert super” haben sie gesagt. m(
Wie dem auch sei: Da UTF-8 an der Stelle zwingend gefordert war, musste sichergestellt werden, dass kein Entwickler, aus welchen Gründen auch immer, ein anderes Encoding einschleust, bzw., wie in diesem Fall, UTF-8 durch falsch konfiguriertes Encoding kaputtspeichert. Ein Ansatz könnte sein, im Git-Repo UTF-8 zu erzwingen. Ein Ansatz dafür kann sein, das Encoding in einem Git-Hook zu prüfen. Anbieten tun sich pre-commit (der erste Hook, der greift; client-seitig; Beispiel [1] [2]) und pre-receive (der erste serverseitige Hook; Beispiel).
[Für Stash/Bitbucket Server scheint es auch Möglichkeiten zu geben; ein fertiges Plugin habe ich aber nicht gefunden.]
pre-commit hat den Vorteil, dass sich keine Commits aufstauen, bevor das Problem auffällt. Dafür müssen lokale Hooks aufwändig verteilt/aktiviert werden – bsplw. über separat eingecheckte Verzeichnisse, die gesymlinkt (aber was ist mit Windows? Was mit wirklich lokalen Hooks? Und was ist noch zu beachten?) oder kopiert werden. Für pre-receive gelten Vor- und Nachteile inversiert, außerdem benötigt man Zugriff auf den Server auf Dateisystemebene.
Lange Rede, kurzer Sinn: Aus Gründen haben wir uns für einen pre-commit entschieden. Das Skript muss dabei .git/hooks/pre-commit heißen. Ich hätte ein Verzeichnis pre-commit mit Skripten darin erwartet, aber das wirft einen
cannot spawn .git/hooks/pre-commit: No such file or directory
Und es war gar nicht so einfach, eine Datei überhaupt mit dem falschen Encoding abzuspeichern. Sublime und Notepad++ haben sich (stillschweigend, was Notepad++ angeht) geweigert. Schließlich habe ich es mit IntelliJ geschafft, was allerdings auch gewarnt hat. Keine Ahnung, wie das ursprüngliche Problem überhaupt zustande kam.
Lokale Kopie des Skripts:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
#!/bin/sh git ls-files -z -- | xargs -0 sh -c ' e="" for f; do if ! git show :"$f" | iconv -f UTF-8 -t UTF-8 >/dev/null 2>&1; then e=1 echo "Not UTF-8: $f" #exit 255 # to abort after first non-UTF-8 file fi done test -z "$e" ' - |
[Achtung: Das Skript kann nicht mit Binaries umgehen! Und das schließt bereits .woff ein. Offenbar ist es auch nicht trivial, Binaries zu erkennen; Internet nutzt dazu die Dateigröße oder auch Fileextensions. Ersteres scheint mir unzuverlässig, man denke an kleine Grafiken. Zweiteres ist sehr aufwändig…]
Beispielhafte Ausgabe (“ISO 8859-1.txt” heißt die Datei):
Und, der Vollständigkeit halber: Die Einstellung von Intellij:
btw: In Eclipse kann man Settings als Textfile exportieren und bsplw. in einem Repo ablegen – in IntelliJ scheint das nur als .jar exportierbar zu sein, bzw. über einen “IntelliJ Configuration Server” (WTF!?) verteilbar?