IllegalStateException wenn TXT-Datei validiert wird about validator HOT 13 CLOSED

Hallo @niwagenk,

ich kann erstmal sagen, dass die Erwartungshaltung richtig ist, es sollte auch bei einer *.txt-Datei ein Report erzeugt werden. Ihr Debugging grenzt die Ursache ja auch deutlich ein, ich kann den Bug aber momentan noch nicht nachstellen. Grundsätzlich haben wir einen Test, der diesen Fall prüfen soll und der auch in der Version 1.4.2 durchläuft. Anders als im Test nutzen Sie direkt einen InputStream.

Ich habe daher folgenden Testfall aufgestellt:

   @Test
    public void testGarbageStream() throws IOException {
        final InputStream inputStream = Helper.Simple.TXT.toURL().openStream();
        final Input input = read(inputStream, "streamed-txt-file");
        final Result result = this.validCheck.checkInput(input);
        assertThat(result).isNotNull();
        assertThat(result.isWellformed()).isFalse();
        assertThat(result.isSchemaValid()).isFalse();
        assertThat(result.isProcessingSuccessful()).isFalse();
        assertThat(result.getReport()).isNotNull();
    }

Dieser läuft ohne Probleme durch und liefert folgende Ausgabe:

2022-02-09 07:56:38 [INFO] Checking content of streamed-txt-file
Error on line 1 column 1 of streamed-txt-file:
  SXXP0003: Error reported by XML parser: Content ist nicht zulässig in Prolog.
2022-02-09 07:56:38 [INFO] No valid scenario configuration found for streamed-txt-file
2022-02-09 07:56:38 [INFO] Finished check of streamed-txt-file in 63ms

Was machen Sie in Ihrem Kontext anders? Wie kann ich den Fehler nachstellen?

from validator.

Ich hab den Quellcode nochmal durchgesehen. Kann es sein, dass Sie einen InputStream nutzen, der über einen HTTP-Request reinkommt? Also direkt den Request-InputStream an den Validator weiterreichen?

Falls dem so ist, könnten Sie mal folgendes probieren:

InputStream peekable =  StreamHelper.wrapPeekable(inputStream);
Input input = InputFactory.read(peekable, "my.txt")
...

Hintergrund: InputStream#available liefert nicht bei allen Streams einen Wert > 0, was im SourceInput aber geprüft wird um zu sagen, ob der Stream schon konsummiert ist. Das ist bspw. bei HTTP-Request Streams der Fall. So richtig nachvollziehen kann ich den Fall aber noch nicht.

Ein simples Beispiel, wie ich das nachstellen kann wäre hilfreich.

from validator.

Hallo @apenski,

nein, wir nutzen keinen InputStream, der über einen HTTP-Request reinkommt. Dass ein so einfacher Testfall bei Ihnen erfolgreich ist, macht mich stutzig. Ich habe nun noch ein paar einfache Testfälle erzeugt und dabei den Umweg über die InputSource entfernt.

Folgende Ergebnisse:
Wenn ich den Input aus einem InputStream erzeuge, tritt besagter Fehler auf. Erzeuge ich den Input hingegen aus einem byte[], gibt es keinen Fehler.

Der folgende Testfall ist erfolgreich:

@Test
public void test_txt_validationtool2()
    {
        final byte[] in = "Nur Text".getBytes();
        
        Check pruefer = getPruefer();
        Input input = InputFactory.read(in, "nicht_wellformed.txt");
        final Result result = pruefer.checkInput(input);
        Assert.assertTrue(result != null);
    }

Erzeuge ich aus dem byte[] einen InputStream, tritt die Fehlermeldung auf:

@Test
public void test_txt_validationtool3()
    {
        final InputStream in = new ByteArrayInputStream("Nur Text".getBytes());
        
        Check pruefer = getPruefer();
        Input input = InputFactory.read(in, "nicht_wellformed");
        final Result result = pruefer.checkInput(input);
        Assert.assertTrue(result != null);
    }

from validator.

Beide Tests laufen bei mir durch. Ich denke da müssen wir uns die Umgebung etwas genauer ansehen. Ich habe das lokal probiert mit:

• Amazon Corretto 11.0.13
• Amazon Corretto 17.0.1
• Amazon Corretto 1.8.0_322

Damit ist erstmal grundsätzlich das Versionspektrum des OpenJDK abgeprüft.

UnitTests laufe im CI darüberhinaus noch mit den Zwischenversionen und auch in Fassungen mit OpenJ9 erfolgreich durch. Das inkludiert auch diesen Test, der ja sehr ähnlich ist.

Welches JDK verwenden Sie?

from validator.

Wir verwenden
Version 1.8.0_271

from validator.

Ich hab in diesem Commit meinen lokalen Stand eingecheckt und durch die interne CI-Pipeline laufen lassen. Das ein Commit direkt auf die getagged Version 1.4.2 ohne weitere enthaltene Änderungen.

Ergebnis:

Ich kann mehr ehrlich gesagt nicht vorstellen, dass die Patch-Versionsnummer (271 vs 322) den Unterschied macht. Welche JDK-Distribution verwenden Sie? Direkt Oracle?

Wenn Sie 1.8 als Java-Version verwenden, welche(s) Jar haben sie eingebunden? Die Standalone-Variante? Wenn ja welche? Oder doch die einzelnen notwendigen Jars selbst (wir haben ja leider noch immer keine Jars in Maven Central 😒 )

from validator.

Hallo @apenski,

genau, wir verwenden eine Oracle-Distribution.
Die Dependencies hatte ich auch schon im Verdacht. Wir haben bis dato die einzelnen notwendigen Jars selbst eingebunden. Analog zum alten Validationtool waren das nur Commons Lang und Saxon. Ich habe eben aber testweise auch die anderen Dependencies hinzugefügt, sowie das Standalone Jar ausprobiert. Am Ergebnis ändert das nichts.
Jetzt kann es natürlich noch sein, dass einzelne Dependencies Konflikte mit bereits eingebundenen Jars verursachen (Commons IO haben wir bspw. schon im Projekt).

from validator.

ich denke nicht, dass die anderen Dependencies da irgendwas mit zu tun haben. Meine Vermutung oben bzgl. InputStream#available halte ich für die Ursache. Ich sehe folgende Möglichkeiten um das einzugrenzen, bzw. zu bestätigen.

1. Verwendung eines anderen OpenJDK (idealerweise Corretto) - nur für Testzwecke um auszuschließen, dass der Fehler nicht doch irgendwas mit dem Classpath zu tun hat. Wen es damit dann geht, dann liegt es am Oracle JDK
2. Nutzen der Wrapper-Methode InputStream peekable = StreamHelper.wrapPeekable(mystream); Dies wäre ein Workaround für InputStream#available

from validator.

Vielen Dank für die vielen schnellen Informationen! Ich werde es ausprobieren und mich anschließend zurückmelden.

from validator.

@apenski: Können Sie die Tests alternativ mal mit der von mir genannten Oracle Distribution ausführen?
Das Wrappen des InputStreams mit InputStream peekable = StreamHelper.wrapPeekable(mystream); hat nichts gebracht.

Also auch folgender Test schlägt fehl:

@Test
   public void test_txt_validationtool3()
   {
       final InputStream in = new ByteArrayInputStream("Nur Text".getBytes());
       InputStream peekable = StreamHelper.wrapPeekable(in);
       
       final Check pruefer = getPruefer();
       final Input input = InputFactory.read(peekable, "nicht_wellformed");
       final Result result = pruefer.checkInput(input);
       Assert.assertTrue(result != null);
   }

Das Corretto OpenJDK habe ich noch nicht probiert.

from validator.

ich kann es mit dem OracleJDK nachstellen. Ich schau es mir mal genauer an

from validator.

Ich denke es handelt sich hierbei um einen Bug im OracleJDK bzw. auch im OpenJDK. Ich hab das eingrenzen können bis zu dem Punkt an dem geöffnete Streams geschlossen werden.

Hintergrund: Das Schließen setzt die parallel zum Einlesevorgang ermittelte Prüfsumme (=DokumentIdentification) des Dokuments, sodass dieses nicht nochmal eingelesen werden muss (was bei Streams eben nicht geht - daher die Exception).

Im OracleJDK und auch OpenJDK gab es einen Bug. Sieht man sich den Fix an, sieht man, dass das eigentlich nicht nur Exceptions betraf, sondern auch jeder normale Zugriff betroffen ist.

Ich konnte das mit Oracle JDK 1.8.0 271 bis zu genau dieser Stelle nachvollziehen. Die Methode closeReaders() macht einfach nichts, wohingegen die aktuellen JDK-Versionen dort die Reader brav in einer Schleife schließen.

Ich rate dringend zu einem Update. Die Oracle JDK Version 1.8.0 271 ist mitlerweile deutlich veraltet und ein Update auf 322 angezeigt.

Sollte das in Ihrer Umgebung nicht möglich sein, besteht ein Workaround darin die Prüfsumme selbst zu setzen:

final InputStream in = new ByteArrayInputStream("Nur Text".getBytes());

final Input input = InputFactory.read(new StreamSource(in), "nicht_wellformed", UUID.randomUUID().toString().getBytes(StandardCharsets.UTF_8));
final Result result = this.validCheck.checkInput(input);
assertTrue(result != null);

Das funktioniert dann auch in der alten Oracle JDK-Version

from validator.

Vielen Dank für die schnelle und gründliche Recherche!

from validator.