Hurray! Vaadin 8 has finally been released and comes up with a bunch of new features. Maybe the most important one is a new data binding concept. But the feature I’m discussing here is support for the HTML5 History API.
CVE-2016-1000031 is a vulnerabilty in the extremely widely used Apache Commons library commons-fileupload – you might not even know you’re having it on your class path. It has a very nasty Remote Code Execution vulnerability with easy to use exploits publicly available up to version 1.3.2. What makes it even worse is that you do not even need to use the library – you only need to have it on your class path and to deserialise some data. The data is the attack vector. You can find a good in detail explanation of the vulnerability here.
It did take a while but with version 1.3.3 this vulnerability is finally closed (by default).
There is some stuff that you should know about the fix though:
I ran across a colleague’s article recently and figured that the Swift programming language would be a nice addition to his comparison. In order to remedy this I implemented the admittedly very simple web service in Swift and measured both its performance and size. Then I followed the given structure of the article in terms of how to present my relevant results. You may find these subsequently.
Oftentimes people talk to each other about using ActiveMQ, but they’re actually referring to different brokers. That is because there are 3 different message brokers with ‘ActiveMQ’ in their name and this turns out to be pretty confusing when a project as big as WildFly starts to use a broker with ‘ActiveMQ’ in its name that is not the broker that was known for years under the name ‘ActiveMQ’.
So there are 3 projects:
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. 🙂
A microservice is an autonomous sub application for a strictly defined and preferably small domain. An application built from microservices is scalable, resilient, and flexible. At least, if the services and their infrastructure are well designed. One requirement on the used frameworks to achieve scalability and resilience is that they are lightweight. Lightweightness comes in different flavors. Microservices should be stopped and started fastly, and should consume few resources. The development and maintenance of microservices should be easy.
For this reason, in the Java world, Spring Boot is currently recommended as best choice regarding these requirements. Traditional Java EE application servers are too heavyweight, because they are not developed as basis for single services but as platform for running different applications simultaneously. Thus, they must be bloated.
Being a curious person I used some of my spare time in the last Christmas holidays to actually measure the lightweightness. First I chose Spring Boot and WildFly as “competitors”. I added WildFly Swarm which provides similar features as Spring Boot but is based on WildFly. Then looking at the requirements I decided to include a framework with a real small startup time in comparison to Java-based frameworks and chose Snap based an Haskell. For every framework I built a minimal micro service, wrapped it into a Docker container, and measured its weight.
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.
Testing your processes is an important tasks to ensure and validate your expected behaviour of your application. An introduction how to do a proper test automation in process applications can be found the following camunda webinar: https://network.camunda.org/webinars/24
A normal approach for testing your processes is to have your actual service implementation mocked or swapped completely to your own implementation for testing purposes. For CDI based java delegates this is an easy task to do within the camunda BPM test environment.
But if your project does not allow you to rely on your favourite CDI or Spring based environment you have to configure your java delegates for service tasks via class name binding. Unfortunately there seems not to be an out of the box approach to test that kind of configuration easily.
Will will show you how to get use of the great extensibility of the camunda BPM engine to have plain java delegates mocked as easy as their CDI/Spring counterparts.
For simple web sites a static web site generator is often sufficient. Jekyll is such a well know generator. In our company we use JBake, because of its good integration in the Java infrastructure. More information on that is found here: Integration of JBake in Maven – Static Websites.
In my nonbusiness life, I like to play with Haskell. This is why I used Hakyll for a small personal web site. I wanted it to be responsive and choose to use Foundation. To do some styling of the Foundation classes I needed to use SASS and embed it into Hakyll. It took me about two hours to put everything together. To save this time in the future, I extracted a small template with everything in it.