System.out per Thread

vorhergehende Artikel in: Java dWb+ Komponenten
29.03.2015

Ich wurde wegen einer neuen Funktionalität für dWb+ zum gründlichen Nachdenken gezwungen...

Problemstellung

Dataflow Workbench dWb+ Die Voraussetzungen für mein Nachdenken über System.out per Thread war die Idee, ganz normale Java-Programme als Module für dWb+ nutzen zu können. Normale Java-Programme meinte dabei solche, die über eine Methode verfügen wie
public static void main(java.lang.String[] args)

Ich wollte das mit einem Modul erreichen, das einen String-Eingang hat, der vom Anwender beliebig vervielfältigt werden kann - je nachdem, wieviele Parameter die Main-Methode erwartet. Als Property des Moduls wollte ich den Namen der Klasse mit der zu startenden Main-Methode definieren. Die Ausgänge des Moduls sollten Stdout, Stderr und Rückgabewert der Ausführung der Main-Methode sein. Diese drei wollte ich dabei noch in eine Bean kapseln.

An diesem Punkt stellte ich fest, dass die Umsetzung nicht so straightforward werden würde, wie ich mir das gewünscht habe: Wie sollte ich an die Streams herankommen? Wenn ich die Methode main einfach aufrufe - was ja per Reflection trivial ist - ist es keine eigene Anwendung und schreibt einfach alle Ausgaben auf die Streams von dWb+ - keine gute Idee...

Einen neuen Prozess zu starten ist ebenfalls nicht uneingeschränkt zu empfehlen: dWb+ benutzt einen eigenen ClassLoader - den könnte man einem neuen Prozess nicht auf einfache Art und Weise mitgeben.

Stdout und Stderr per Thread

Man könnte statt dessen die Streams für Stdout und Stderr der Anwendung dWb+ durch eine eigene Implementierung ersetzen, die abhängig vom Thread, der in diese hineinschreiben möchte, unterschiedlich reagiert. Dann könnte man zum Beispiel an dieser Implementierung Visitors registrieren. Setzt man das beschriebene Modul als ThreadedModule um, kann man auf den Threadnamen zugreifen und für die Ausführung der main-Methode dann Streams registrieren, in die alle Ausgaben dieses Threads umgeleitet werden.

Klingt wie eine elegante Methode - und der Geek in mir jubelte bereits darüber. Im Lichte der speziellen Anforderungen jedoch habe ich - unterstützt durch Informationen von Tante Unbubble - mich gegen diese Variante entschieden: Damit laufen Anwendungen im Kontext des Prozesses dWb+ , über die ich keine Kontrolle habe. Damit haben sie die Kontrolle über alle Singletons in der JVM. Das potentielle Problem damit lässt sich am einfachsten mit dem Szenario beschreiben, dass im Zuge der Ausführung der Anwendung, zu der die betreffende main-Methode gehört, die System.out und System.err Printwriter gesetzt werden - damit ist meine schöne Thread-spezifische Implementierung unwiederbringlich verloren und die Instanz dWb+ ist kaputt. Dazu kommt natürlich noch, dass in den Anwendungen, die über die main-Methode gestartet werden, unter Umständen die Methode System.exit aufgerufen werden könnte, was natürlich die Anwendung dWb+ sofort beenden würde - nein: für mich ist in diesem vorliegenden Fall eine Thread-spezifische Implementierung der Standard-Streams wirklich keine Option.

Die Lösung

Ich entschied mich daher dafür, die Lösung zwar trotzdem zu implementieren - und sei es auch nur als Fingerübung - das Problem für dWb+ aber anders zu lösen: Ich starte dort jetzt einen Prozess, der zunächst den in dWb+ benutzten ClassLoader aufsetzt und ihn zum ContextClassLoader macht. in diesem Prozess rufe ich dann einfach die main-Methode auf.

Alle Artikel rss Wochenübersicht Monatsübersicht Github Repositories Gitlab Repositories Mastodon Über mich home xmpp


Vor 5 Jahren hier im Blog

  • Fährnisse des Buildprozesses unter Windows

    17.07.2019

    Nachdem ich begonnen hatte, mich mit der Beschleunigung der Berechnung des Mandelbrot-Fraktals unter Zuhilfenahme der Shadereinheiten in Graphikkarten zu beschäftigen und erste Erfolge feiern konnte, wollte ich das mal auf einer richtigen Graphikkarte ausprobieren...

    Weiterlesen...

Neueste Artikel

  • Datenvalidierung UTF8 mit BiDi-Steuerzeichen (TrojanSource 2.0)

    Ich bin heute nochmal inspiriert worden, weiter über die Trojan Source Vulnerability nachzudenken. Meiner Meinung nach bestehen hier noch Probleme - speziell bei Nutzereingaben oder Daten, die über externe Schnittstellen ampfangen werden.

    Weiterlesen...
  • OpenStreetMap Navi als Docker-Container

    Ich habe die auf OpenStreetMap basierende OpenSource Navigationslösung Graphhopper in einen Docker-Container gepackt und als neuestes Mitglied in meinem Docker-Zoo willkommen geheißen.

    Weiterlesen...
  • SQL-Aggregatfunktionen in SQLite als BeanShell-Scripts

    Ich habe neulich über eine Möglichkeit berichtet, SQLite mittels der sQLshell und Beanshell-Skripten um SQL-Funktionen zu erweitern. In diesem Artikel versprach ich auch, über eine solche Möglichkeit für Aggregatfunktionen zu berichten.

    Weiterlesen...

Manche nennen es Blog, manche Web-Seite - ich schreibe hier hin und wieder über meine Erlebnisse, Rückschläge und Erleuchtungen bei meinen Hobbies.

Wer daran teilhaben und eventuell sogar davon profitieren möchte, muß damit leben, daß ich hin und wieder kleine Ausflüge in Bereiche mache, die nichts mit IT, Administration oder Softwareentwicklung zu tun haben.

Ich wünsche allen Lesern viel Spaß und hin und wieder einen kleinen AHA!-Effekt...

PS: Meine öffentlichen GitHub-Repositories findet man hier - meine öffentlichen GitLab-Repositories finden sich dagegen hier.