Roy T. Fielding wrote and described REST in his dissertation in the 2000's. He basically told about the an architectural pattern and mapped it to most common protocol: HTTP

Since these days the IT community began to realize and to understand more and more what it means to deal with resources, what power and strength HTTP provides. But what's so special about it? And why does everybody talk about it but the least understood it? Why is today everything called REST, but in fact it's not REST? Let's dig into it.

Exceptions, ja, was sind eigentlich Exceptions? Exceptions sind zu deutsch Ausnahmen. Und im Grunde genommen stellen Exceptions und der Umgang mit ihnen genau das gleiche dar, wie der Umgang mit Business Logik. Exceptions sind nur ein eleganterer Mechanismus. Dieser erlaubt es, in Ausnahmesituationen (unerwartete Parameter, Fehler bei Dateizugriffen) eine adäquate Reaktion zu ermöglichen.

Exceptions, yes, what are exceptions? Exceptions are situations, where the planned flow cannot be completed anymore. So they are exactly the same as dealing with business logic. Exceptions are only a more elegant mechanism. They allows us to provide in an emergency case (unexpected parameters, errors in file access) an adequate response.

In many software systems and use cases there are exceptions. Exceptions, that are triggered by conditions that do not allow the expected sequence (ideally). These exceptions and dealing with those are hiding behind the lapidary used "exception handling". A fast-created try-catch is often not the solution. And in those cases in which exceptions are forwarded to the client, there are some pitfalls.

In vielen Software-Systemen und Use Cases gibt es Ausnahmen. Ausnahmen, die durch Zustände ausgelöst werden, die nicht den erwarteten Ablauf (Idealfall) ermöglichen. Diese Ausnahmen und der Umgang verbirgt sich hinter dem lapidar benutzten "Exception Handling". Dabei ist ein schnell erstellter try-catch oftmals nicht die Lösung. Und in den Fällen, in denen Exceptions an den Client weitergeleitet werden, gibt es einige Fallstricke.

Vor ca. einer Woche habe ich den Quellcode meines JBoss Development Deployers auf GitHub migriert. Das Repository ist unter https://github.com/mp911de/JBoss-Development-Deployer erreichbar. Happy social coding!

Erst neulich habe ich meine Server konsolidiert und virtualisiert. Aus 3 Root-Servern habe ich zu einem größeren Root-Server mit virtualisierten Sub-Systemen zusammengeführt.

Häufig wird die Anforderung gestellt, Aufgaben im Hintergrund zu verarbeiten. Durch den Trend der Webanwendungen trifft früher oder später diese Anforderung auch auf ein Web-Projekt zu. Erst kürzlich kam dieselbe Frage in der JBoss Community auf.

Vor nicht allzulanger Zeit, da gab es mal ein Projekt, in einem nicht weit entfernten Land. Und was jetzt folgt ist keine Gute-Nacht-Geschichte. In einem meiner Projekte gab es folgendes Setup: JBoss, Hibernate mit Cache und einen Cluster

Ein regulärer Stack für Enterprise-Projekte. Das System funktionierte zuverlässig und führte in regelmäßigen Abständen zu unterschiedlichen Daten auf den verschiedenen Nodes (bei den selben Objekten)

Im ersten Teil ging es um die Top 5 Ursachen für Performance-Probleme in Java und J2EE-Umgebungen. Nun will ich mich den anderen Ursachen widmen, die zu Lasten der Performance gehen.