WildFly 14 released

WildFly 14 has been released and is now Java EE 8 certified. From now on, WildyFly only provides EE8 APIs by default in all its run modes. The Java EE 8 preview option and Java EE 7 mode have been dropped.

Since Java EE 8 is backwards compatible, Java EE 7 and older applications will still run in the new WildFly version.

Besides the promotion of Java EE 8 as new default mode, WildFly 14 comes with some new standards for Eclipse MicroProfile. The new APIs  MP Config, MP OpenTracing and MP Health are now part of WildFly 14 and will help with the use of container environments.

Another new improvement is a high performance connection pool, provided by the Agroal project, although JCA is still activated by default.

The complete list of all new additions can be found in the release notes.

Posted in Java Runtimes - VM, Appserver & Cloud | Tagged , , , | Leave a comment

Working with Maven dependencies not found in public repositories

One of the many pleasant advantages the dependency management of a modern build tool such as Maven or Gradle gives you is that you simply declare the set of dependencies your application needs and the build tool then takes care of downloading them together with their transitive dependencies from a public repository. There’s no need to painstakingly assemble these by hand and later having to hassle with updating them to some newer version. The times when you had to manage a lib directory in your project by hand are luckily long over (anyone remember Ant?).

But what if your project depends on some library that cannot be found in a public repository, either because it is proprietary or because it was never uploaded into any repository in the first place? How can you include such a dependency into the build process anyway? There are basically four options which will be discussed in this article.
Continue reading

Posted in Build, config and deploy | Tagged , | Leave a comment

Eine Einführung in OAuth 2

Bei OAuth2 handelt es sich um ein weitverbreitetes Autorisierungsprotokoll, laut eigenen Angaben ein “Industry Standard”. Die neue Version 2 ist der Nachfolger der ersten, nun obsoleten Version von OAuth. Entwickelt wird OAuth von der gleichnamigen IETF OAuth Working Group. OAuth2 ist in RFC 6749 ausspezifiziert.

OAuth2 soll den Zugriff dritter Parteien auf HTTP-Services und -Ressourcen mittels einer Bestätigung durch den Benutzer und einem feingranularen Berechtigungssystem vereinfachen.

Die Kernidee ist dabei, das übliche Loginverfahren mit Username/Passwort durch ein besseres System zu ersetzen, da es beim Username/Passwort-Ansatz einige Mängel gibt. So müssen etwa die Klartextpasswörter auf einem Server der dritten Partei gespeichert werden, da sie ja für jeden Login benötigt werden. Außerdem kann der Zugriff durch die dritte Partei nicht reguliert werden. Das Resultat ist in dieser Abbildung zu sehen:

Kapselung des Ressourcenzugriffs: Zugriff ohne Kapselung und gekapselter Zugriff

Kapselung des Ressourcenzugriffs: Zugriff ohne Kapselung (oben) und gekapselter Zugriff (unten)

Mit Username/Passwort erhält das Client-Gerät direkten Zugriff auf das gesamte Benutzerkonto und alle verbundenen Ressourcen (in der Abbildung oben). Es ist nicht möglich, der dritten Partei nur Zugang zu ausgewählten Teilen oder Ressourcen zu gewähren. Dieser ressourcenlimitierende Ansatz, wie in der Abbildung unten vorgeschlagen, wäre jedoch viel sicherer und praktischer.

Bei OAuth2 werden diese für die Sicherheit eher problematischen Login-Credentials abstrahiert. Dazu gibt es mehrere Rollen, die von einem Dienst, Benutzer oder Server eingenommen werden können. Um das Zugriffsproblem zu lösen, gibt es außerdem ein Berechtigungssystem mit Einzelberechtigungen. Zusätzlich gibt es zwei grundlegende Client-Typen: Der Confidential Client und der Public Client. Aber zuerst einmal zurück zu den Rollen und dem Berechtigungssystem.
Continue reading

Posted in Security | Tagged , , , , , | Leave a comment

Java Optional – Endlich so, wie es schon immer sein sollte

Seit Java 8 gibt es die Optional-Klasse, die mittlerweile bestimmt fast jeder schon einmal genutzt oder zumindest gesehen hat. Da in Java der Umgang mit optionalen Objekten und damit verbunden null ja leider nicht so elegant ist wie in manch anderen Sprachen, ist Optional angetreten, um genau diesen Umstand zu verbessern.

Man kann an einem Optional unter anderem

  • abfragen, ob ein Objekt wirklich vorhanden ist: boolean isPresent()
  • sich das Objekt zurückgeben lassen: T get()
  • das gesetzte Objekt oder ein alternatives Objekt zurückgeben lassen:
    T orElseGet(Supplier<? extends T> alternative)
  • oder direkt Code mit einem vorhandenen Objekt ausführen lassen:
    void ifPresent(Consumer<? super T> consumer).

Was der API gefehlt hat, war eine schöne, prägnante Lösung für den Anwendungsfall “wenn ein Objekt vorhanden ist, führe folgenden Code aus, ansonsten führe diesen alternativen Code aus”.  Mit der bisherigen API sah das Ganze nämlich immer so oder so ähnlich aus:

Optional<Item> nextItem = loadNextItem(); 
nextItem.ifPresent(Item::process); 
if(!nextItem.isPresent()) { 
    latch.countDown(); 
}

Verständlich…ja…schön…eher nein. Zumindest nicht, wenn man bedenkt, dass mit Optional ja alles besser werden sollte. Erfreulicherweise wurde die Optional API in Java 9 um folgende Methode erweitert:

void ifPresentOrElse​(Consumer<? super T> action, Runnable emptyAction).

Mit dieser Methode lässt sich oben beschriebene Anforderung elegant in einem Einzeiler folgendermaßen lösen:

loadNextItem().ifPresentOrElse(Item::process, latch::countDown);

(Codebeispiele entnommen aus https://bugs.openjdk.java.net/browse/JDK-8071670)

Posted in Java Basics | Tagged , | 1 Comment

Bessere Docker Java Images dank Jib

Google hat mit Jib ein neuen “Containerizer” vorgestellt, der die Erstellung von Container Images für Java Entwickler deutlich vereinfachen soll. Das nächste neue Ding, das durchs Container-Dorf getrieben wird?

Ein Java Entwickler, der seine Applikation als Docker Image ausliefern will, hat gewisse Hürden zu überwinden. Die Applikation muss in den Container, die Start-Skripte wollen geschrieben werden und natürlich muss ein geeignetes Basis Image ausgewählt werden. Das ist nur die Spitze des Eisbergs. Natürlich wollen auch die Build-Tools konfiguriert, die Container-Umgebungen installiert und die Shell-Skripte zum Starten und Stoppen der Anwendung geschrieben werden. Teile davon können die entsprechenden Plugins für das jeweilige Build-Tool übernehmen.

Aber geht es noch einfacher? Googles Antwort drauf: Jib!
Continue reading

Posted in Build, config and deploy | Tagged , , | Leave a comment

Eclipse MicroProfile 1.4 und 2.0 erschienen

In der Java EE (Jakarta EE) Welt passiert derzeit scheinbar nicht allzu viel, Planungen für eine Version 9 sind aktuell noch nicht in Sicht. Vielmehr kostet die Transition von Oracle zu Eclipse EE4J im Moment viel Arbeit und Zeit. Dagegen entwickelt sich die MicroProfile Initiative rasant weiter. Hier hat man sich eine Plattform geschaffen, um unabhängig vom bisher eher langsamen und schwergewichtigen Standardisierungsprozess von Java EE neue und innovative Ideen im MicroService- und Cloud-Umfeld angehen zu können. Trotzdem wird zukünftig der Java Enterprise Standard auch davon profitieren, wenn nämlich aus dem Inkubator MicroProfile die ein oder andere Spezifikationen übernommen wird.

Vor einigen Tagen wurden nun zwei neue Versionen veröffentlicht. Während beim mit Java EE 7 kompatiblen MicroProfile 1.4 fünf der elf Teilspezifikationen aktualisiert wurden, hat man für das MicroProfile 2.0 die vorhandenen Spezifikationen an die Neuerungen von Java EE 8 angepasst (u. a. CDI 2.0, JSON-P 1.1 und JAX-RS 2.1). Neu hinzugekommen ist außerdem die API für JSON Binding (JSON-B), ein Werkzeug, um analog zu JAXB (XML Binding) Java Objekte von und zu JSON Nachrichten zu konvertieren. Die Version 2.0 ist nun auch die Basis für die weitere Entwicklung.

MicroProfile 1.4
Quelle
MicroProfile 2.0
Quelle

Weitere Infos zu den neuen Releases kann man im MicroProfile-Blog nachlesen. Die Release-Notes finden sich hier und hier.

Posted in Java EE | Tagged , , , , | Leave a comment

WildFly Swarm heißt jetzt Thorntail

RedHat/JBoss ist bekannt dafür, seinen Produkten mal einen neuen Namen zu geben. So wurde vor 5 Jahren der JBoss AS in WildFly umbenannt, um den Open Source Application Server besser von den anderen Teilen in der JBoss Produktfamilie abzugrenzen. Und aus den gleichen Gründen hat man nun WildFly Swarm, den Java-EE-Microservice-Verpacker, in Thorntail umgetauft. Thorntails sind im Englischen übrigens verschiedene Kolibri-Arten, die in Südamerika vorkommen.

Gleichzeitig mit der Umbenennung wird sich das bisherige Namensschema (2018.5.0) ändern. Durch die monatlichen Versionsänderungen kam nie so richtig das Gefühl für eine stabile Version auf. Darum wagt man mit Thorntail nun den Neuanfang als Version 2.0.0.Final. Als nächste Schritte will man ein neues Logo entwerfen, den Code in ein neues Github-Repo umziehen, dabei die Maven-Group-IDs ändern und die Namen der Kommunikationskanäle (Twitter, …) anpassen. Die Mailingliste ist bereits umgezogen und von der Dokumentation gibt es ebenfalls bereits eine neue Version.

Thorntail bietet ähnlich wie Spring Boot die Möglichkeit, mit Java EE Microservices Architekturen zu entwickeln, in dem einzelne Services als ausführbare JAR-Archive mit genau so viel Applikationsserver wie nötig zusammengepackt werden. Gleichzeitig ist Thorntail auch eine Implementierung des Eclipse MicroProfile Standards. Weitere Infos findet man bereits unter der neuen Webseite.

Posted in Java EE, Java Runtimes - VM, Appserver & Cloud | Tagged , , , , | Leave a comment