Error: No package erlang available.

If you are trying to install Erlang on CentOS/7 you might be presented with the following errors:

Screen Shot 2016-05-03 at 17.11.57

These errors mean you don’t have the updated RHEL EPEL Repo from which to fetch Erlang builds. You update your repo as follows:

Screen Shot 2016-05-03 at 17.33.13

Screen Shot 2016-05-03 at 17.33.32

Screen Shot 2016-05-03 at 17.33.47

Retry installing Erlang.

Screen Shot 2016-05-03 at 17.37.17

For centos 5 and 6 visit this blog post.

Thanks to jake_morrison from Reddit who posted this response.

The Erlang packages in the distro are not kept up to date, and go stale pretty quickly with the pace of Erlang development.

It’s better to use the packages from ESL:

Relevant Ansible tasks:

- name: install esl key
  rpm_key: state=present key=
  become: true

- name: install esl repo
  copy: src=etc/yum.repos.d/erlang-solutions.repo dest=/etc/yum.repos.d/
    erlang-solutions.repo owner=root group=root mode=0644
  become: true

- name: install erlang
  yum: name=erlang state=latest update_cache=yes
  become: true

See original reply here.

Configure Tomcat 9 for HTTP/2

One of the most significant advancements in JavaEE 8 is support for HTTP/2. Three server vendors currently support servlet 4.0, Apache Tomcat 9.0.0.M4, Jetty 9 and WildFly 10.0.0.Final. Lets have a look at how to configure Tomcat 9 to support HTTP/2.

I often post about Servlet 4.0 on Twitter. Follow me here

Java EE Revisits Design Patterns

This and subsequent posts are a write up of my Java EE revisits design patterns talk at jDay Sweden 2016.

The slides to the presentation are viewable here: Java EE Revisits Design Patterns and a video of the presentation will be made available as soon as jDays publish it.

The book that accompanies this talk is available from Amazon.

qMaster Java EE design pattern implementation to improve your design skills and your application’s architecture

Professional Java EE Design Patterns is the perfect companion for anyone who wants to work more effectively with Java EE, and the only resource that covers both the theory and application of design patterns in solving real-world problems. The authors guide readers through both the fundamental and advanced features of Java EE 7, presenting patterns throughout, and demonstrating how they are used in day-to-day problem solving.

The talk has been divided up into the following sections.

Design patterns: the beginning

The beginning

Where did they come from? Did they just appear overnight? In fact design patterns have a long history starting way before computing. But it wasn’t really until the GOF wrote their seminal book Design Patterns: Elements of Reusable Object-Oriented Software, that the concept of design patterns was cemented in the world of software development. The book introduces a list of design patterns categorised under three titles: creational, behavioural and structural.

So what are design patterns in practice? Design patterns are solutions to problems already solved. They represent the collective wisdom of developers and provide us with a common vocabulary. By implementing solutions that are proven to work we avoid reinventing the wheel and can focus our efforts on solving the other problems we will face as we develop our application.

However, we need to take care not to overuse them. Unnecessary use of patterns tends to overcomplicate code making it hard to maintain and poor design pattern knowledge leads to the inappropriate implementation of patterns to problems that they were not designed to solve. It is very much the case that: If the only tool you have is a hammer, then you will see every problem as a nail.

The book’s authors are Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides.

Enterprise Java and design patterns

After the GoF published their book, there was a talk at Java One 2000 about prototyping patterns for the J2EE platform this talk became success and the speakers published the talk as a book. Core J2EE Patterns

The GoF book describes a range of patterns, not all common in Enterprise Java, but those that are common are baked into the APIs of the platform, so instead of having to implement them yourself the platform has them ready to use out of the box. This had already happened by Java EE 5.

Java EE Programming Model

The Java EE programming model has been simplified substantially since J2EE. Annotations have replaced the XML description files, convention over configuration has replaced the tedious manual configuration and dependency injection hides the creation and look up of resources.

Resources are created and injected at injection points marked by annotations such as @Inject. All you need is a POJO that meets all of the conditions of the managed beans specification JSR 299 and depending on the annotation used it will become an EJB, servlet, singleton or RESTful web service.

The object is injected by the container and is determine by type. However using an interface as a type can confuse the container if there is more than one concrete implementation. It doesn’t know which object to inject. This confusion can be resolved by the use of a qualifier annotation that marks the concrete implementation you want to implement. We will see how this annotation is used with @Produces in the implementation of the factory pattern. Beans or objects that you want to inject that do not conform to JSR299 use the @Produces annotation to make them injectable.

JSR 299 Managed bean specification

  • It is not a nonstatic inner class.
  • It is a concrete class or is annotated @Decorator.
  • It is not annotated with an EJB component-defining annotation or declared as an EJB bean class in ejb-jar.xml.
  • It has an appropriate constructor. That is, one of the following is the case:
  • The class has a constructor with no parameters.
  • The class declares a constructor annotated @Inject.

No special declaration, such as an annotation, is required to define a managed bean. To enable CDI you must have a beans.xml file in your project (under the META-INF or WEB-INF).