Inspired by my article The lightweightness of microservices – Comparing Spring Boot, WildFly Swarm, and Haskell Snap, a colleague of mine implemented the same Web service using the Go programming language. You can find his code here: Bitbucket-repo. To compare his implementations with the other ones, I integrated it into the main project (GitHub-repo) and measured it. Here are the results. 🙂
In one of our recent projects we have encountered some memory leaks using standard JavaEE technologies like CDI and EJBs. Our application in question does a lot of communication using JMS as a transportation layer. To be able to handle different message types dynamically we have used the Instance Injection of CDI. Using that approach with CDI might get your trapped into some memory leak problems like we did, so we would like to share our experiences and what you can do about it.
We are migrating an existing Java EE Application from JBoss AS 6 to JBoss AS 7. This blog post introduces our experience we have gained during the migration of the application to the new JBoss AS 7.
Overview of the application
The application is a Java EE application based on EJB, JPA and it contains a web application built with JSF. Furthermore, the application contains a web service to interact with a third-party system and some MBean’s for administration and configuration.
CDI introduced a convenient implementation of the observer pattern into the JavaEE world. Using the CDI API, components can emit events, or receive events created by other components (using the @Observes annotation). This allows developers to reduce the coupling between the emitters and the receivers of events.
However, the current API does not allow to handle what we call “global” events. Global events are propagated among all active sessions, i.e., current users and are not restricted to the current session.
This blog post briefly explores the CDI observer pattern and explains how it can be extended to support global events.
Let’s imagine the following situation. You’re working on an application for a customer. Despite a firm deadline and a roadmap given to your customer, he’d like to check the progress regularly, let’s say weekly or even daily, and actually give you feedback.
So to make everybody happy, you start releasing the application weekly. However, releasing is generally a hard-core process, even for the most automated processes, and requires human actions. As the release date approaches, stress increases. The tension reaches its climax one hour before the deadline when the release process fails, or worse, when the deployment fails. We’ve all been in situations like that, right?
This all-too-common nightmare can be largely avoided. This blog post presents a way to deal with the above situation using Jenkins, Nexus and SSH. The application is deployed continuously and without human intervention on a test environment, which can be checked and tested by the customer. Jenkins, a continuous integration server, is used as the orchestrator of the whole continuous delivery process.
akquinet tech@spree has published a technology radar analyzing the trends of 2011–2012. It provides an overview of the evolution of practice in the Information Technology sector in 2011 as well as a forecast for 2012. It is the result of one year of analysis and synthesis performed by the Innovation department of akquinet tech@spree.
The technology radar captures the output from discussions, experiments, projects, and feedback from customers and developers. It synthesizes the results to inform global technology strategy decisions. It focuses on new technologies and methodologies with a high level of attraction. This document does not aim to provide an in-depth presentation of each technology, focusing instead on conciseness and highlighting the trends and state of the practice.
More information on http://radar.spree.de