In No more Ifs I wrote a little bit about the new Optional class in Java 8. It enables the developer to work with optional values without a complex nested structure of if-then-else expressions. A colleague of mine, being a big fan of Kotlin, dropped a hint that using Kotlin, it would be much easier. He could even prove it. 🙂
Java 8 introduced with
Optional a functional datatype that enables the developer to work with optional values without nested if-statements. This can simplify your code a lot.
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.
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.
We are happy to announce the Hibersap 1.2.0 release!
The artifacts for the new Hibersap version can be found in Maven central.
Besides the enhancements, we changed the license under which the Hibersap project is distributed from the Lesser GNU Public License (LGPL) to the Apache License. This should make it easier to integrate Hibersap with other libraries.
Read more: http://hibersap.github.io/news/2015/03/13/hibersap-1-2-0-released/
Artikel in deutsch ⤴︎
Also the access control can be implemented using the standard Java EE tools. Using form-based authentication, a user first has to enter login and password before he can access the web pages. In addition to the web pages the servlet used by the AngularJS application can be secured in the same way.
That should solve all problems, am I right? Almost. What is not covered by default is the handling of session timeouts. When a session times out the user is redirected to the login page to establish a new session. This is fine for a human user. An AngularJS application can get quite confused. It access the server in the background, expects a JSON response, and receives instead an HTML page. Here, we show a solution for this problem.
The good old JBoss Seam framework introduced the usage of stateful session beans (SFSB) as backing beans for JSF applications. The trick was to bind the lifecycle of a SFSB to a web context, such as the session or the request context. Meanwhile this concept was integrated into the Java EE by the Context and Dependency Injection (CDI) specification. We really like to use SFSB in JSF because it provides a comfortable way to access the logic and persistence layer with an automatic and painless transaction management.
We also like to modularize our applications by separating its different layers into different Maven modules. Thus, usually the web and application logic are bundled as EJB archives, whereas the web pages are stored in a WAR archive. All modules are combined to an application as an EAR archive. In our opinion this approach is more maintainable than to mix everything into one big WAR archive.
Sometimes the web logic has to access JSF classes, i.e. to query the locale used in the current request. To do this with the JBoss EAP 6, a particularity must be taken into account. By default in the EAP6 only WAR archives containing a JSF descriptor have access to the JSF classes, EJB jars do not.
This is due to rules for implicit class loading dependencies which are added automatically by the application server at deployment time. To access JSF classes from an EJB archive, the EJB jar has to state an explicit dependency to the faces module. This is pretty simple, if you know how to do it.
The last months, I often looked at web pages of projects using JSF and discovered an extensive use of the tag
h:outputText. It needs some practice to fast read HTML pages. But if the pages are cluttered with additional tags they become unreadable. When I asked the developer, why they designed the page like this, I often got the impression it was because they found it in the web or in some other part of the application, copied the code, and adapted it. This is a valid approach if the adaption phase contains improvement and consolidation. But, because of some uncertainty when to use the tag and when not to use it, the code was not cleaned up. Thus, I decided to write a short post, adding my 2 cents to the story.