Diese Woche haben sich 800 Entwickler und Enthusiasten bereits zum zweiten Mal in diesem Jahr zu den ScalaDays zusammengefunden. In insgesamt 106 Talks wurden auf drei Tracks verteilt die Themen Enterprise-Scala (Reactive und BigData), Core Scala (Functional und Academic), Tools und Web sowie IoT & Cool Stuff angesprochen.
weiterlesen
Am 27. April findet das zweite Akka-Meetup in Hamburg in diesem Jahr statt — dieses Mal zu Gast in unserem Büro in Othmarschen. Wir freuen uns auf Markus Jura (@MarkusJura) von Typesafe. Die Anmeldung erfolgt wie üblich über die Meetup-Gruppe.
Nur noch selten findet das Hamburg Web Performance Meetup statt. Daher freuen wir uns um so mehr, auch für das 21. Meetup wieder zwei Sprecher gewonnen zu haben: Markus Winand & Tobias Dreyschultze werden zu Gast sein. Das Ereignis wird am 15. April 2015 bei uns im Haus stattfinden.
Die Entwicklung des Frameworks TracEE schreitet mit großen Schritten voran, so dass wir (Daniel, Tobi und ich) bald die erste Version mit stabiler API herausbringen wollen. Was TracEE genau ist, hatten wir in einem vergangenen Blog-Beitrag bereits sehr ausführlich erwähnt. In wenigen Sätzen erklärt: TracEE erzeugt einen Invocation-Context im MDC und sorgt mit den Bindings dafür, dass dieser bei allen Aufrufen mitgegeben wird. Alle Log-Einträge enthalten diese Informationen und lassen sich so einfach nachvollziehen. Vor allem für das Monitoring von Microservice-Architekturen ist ein solcher MDC in den Log-Meldungen wünschenswert: Ein Frontend-Service empfängt einen Request und ein Filter erzeugt eine InvocationId. Dieser Service ruft zwei weitere Microservices auf, die getrennt deployed werden. Egal ob REST, SOAP oder etwas anderes: TracEE trägt den MDC des Logging-Frameworks weiter — es überträgt den MDC sogar im Response wieder zurück! Wir nennen diese Abbildung TPIC – TracEE Propagated Invocation Context.
In einer Aggregation der Log-Einträge (z.B. über Splunk oder einen ELK-Stack – ElasticSearch, Logstash, Kibana) werden die Zusammenhänge mittels invocationId und (pseudonymisierter) sessionId sichtbar:
Durch diese IDs wird überhaupt erst sichtbar, dass Alice auf einen Fehler im Programmablauf aufgelaufen ist — und nicht Bob. Da das Backend z.B. via REST angesprochen wurde, sind die aus Application-Servern bekannten Thread-IDs bei der Korrelation von Log-Meldungen nicht sehr hilfreich.
TracEE ist und bleibt weiterhin OpenSource und auf GitHub verfügbar. Da wir das Projekt aber nicht als alleiniges Holisticon-Projekt sehen und uns über jegliche Mithilfe, konstruktive Kritik und Code-Beiräge sehr freuen, haben wir das Repository in eine eigene GitHub-Organisation verschoben. Zudem haben wir die Context-Logger aus dem Hauptprojekt herausgelöst und in ein Tochter-Projekt überführt. Auch die Beispiele wurden in ein separates Repository verschoben und helfen dir bei der Integration in deine Projekte.
Apropos Integration: Uns erreichte die Kritik, dass die Dokumentation zwar die Zusammenhänge gut erklärt, die Integration mit den einzelnen Technologien aber überarbeitungswürdig ist. Diese Module heißen Bindings und übertragen z.B. den TPIC von einem Apache CXF-Client auf einen JaxWS-Server. Diese Dokumentation haben wir für sämtliche Bindings nachgepflegt und über die Hauptseite verlinkt. Auch die Unterseite der Bindings enthält die entsprechenden Links.
Des weiteren wurden viele Technologien abseits des JavaEE-Stacks als Binding integriert. Neu seit dem letzten Blog-Artikel sind folgende Integrationen:
Diese wurden in Teilen von den ersten early-adoptern implementiert und in Form von Pull-Requests an das TracEE-Projekt gegeben. Interessant an dieser Stelle sind die Quartz-Scheduler. Diese oft für die Batch-Verarbeitung genutzten Jobs werden zeitlich gesteuert und stellen somit eigentlich keinen echten Request dar. Trotzdem möchte man durch einen Job ausgeführte SOAP- oder REST-Anfragen auch diesem Job zuordnen können. Daher haben wir beschlossen, den Begriff RequestId durch das generellere Konzept einer InvocationId abzulösen.
Zuallererst: Du integrierst einfach mal TracEE in dein Projekt und berichtest uns und der Welt von den Vorzügen eines einheitlichen Contextes. Bei Fragen und Problemen freuen wir uns auf dein Feedback oder deine Beiträge auf Github. Für die schnelle Hilfe haben wir für TracEE einen Gitter-Kanal eingerichtet.
Außerdem arbeiten wir gerade an einer Integration in Spring WS und überarbeiten gerade die Context-Logger-Struktur. Falls Du noch immer nicht überzeugt sein solltest, kannst du auch auf unsere Blog-Serie warten. In dieser werden wir auf die Vorzüge eines zentralisierten Log-Systems eingehen und zeigen, wie TracEE und Context-Logging dir hilft, z.B. Bugs oder Abläufe über die Systemgrenzen besser nachzuvollziehen. Und irgendwann dann werden wir die 1.0 releasen.
Will man testgetrieben entwickeln (bzw. überhaupt Unit-testen) und gleichzeitig mit einem Dependency Injection Framework arbeiten, steht man zwangsläufig vor einem wesentlichen Problem beim Aufbau der Tests: Wie bekomme ich die, mitunter komplexen, Abhängigkeitsnetzwerke meiner Komponenten pro zu testender Unit aufgebaut oder besser gekapselt (bzw. gemockt)? Schließlich erfolgt die DI zur Laufzeit durch ein komplexes Framework, das ggf. aufwändig konfiguriert werden muss und wegen der Objekt-Beziehungen der Anwendung selten ohne Nebeneffekte ist, sprich sich für einzelne Klassen (die Unites-under-Test) nicht bzw. schwer isolieren lässt.
weiterlesen