Migrating to Lagom 1.4.x in Java

This blog will help you to migrate your Lagom service from 1.3.x to 1.4.x. Here, I have shared few of the things that need to be considered while migrating your Lagom version.

Play and Akka version supported:

Lagom 1.4 updates to the latest versions of PLAY(2.6) and AKKA(2.5). That means, the part of the code that uses Play and Akka APIs directly, needs to be modified. With this, any Play services in your Lagom project repositories need to be updated to be compatible with Play 2.6. I have used Play version 2.6.12 and Akka version 2.5.11 with Lagom version 1.4.4.

Support for Scala 2.12:

Scala libraries in a maven project should have a version as 2.12. So, replace all references to _2.11 by _2.12. and for easing out the work, consider adding Scala version in maven properties of parent pom.xml. For example,

<properties>
  <lagom.version>1.4.4</lagom.version>
  <play.version>2.6.12</play.version>
  <scala.binary.version>2.12</scala.binary.version>
</properties>

After having these version added as maven properties, we can access them by their names.

<dependency>
  <groupId>com.lightbend.lagom</groupId>
  <artifactId>lagom-javadsl-api_${scala.binary.version}</artifactId>
  <version>${lagom.version}</version>
</dependency>

Default Server Engine:

Play 2.6 introduces a new default server engine implemented using Akka Http instead of Netty. However, support for Netty isn’t dropped.

<dependency>
<groupId>com.typesafe.play</groupId>
<!--<artifactId>play-netty-server_2.12</artifactId>-->
<artifactId>play-akka-http-server_2.12</artifactId>
</dependency>

Deprecations: 

Configuration API: 

The class play.Configuration was deprecated in favor of using Typesafe Config directly. So,  you must now use com.typesafe.config.Config.

The class CircuitBreakers of com.lightbend.lagom.internal.client got deprecated. so, in place of CircuitBreakers, we must now use CircuitBreakersPanel of com.lightbend.lagom.javadsl.client.

 

Using dependencies which are on Lagom version 1.3:

If the service to be included as a dependency is supposedly on Lagom version 1.3 and the service which is being upgraded is on Lagom version 1.4, then ambiguity between dependencies may arise because of different Lagom versions. In this case, one can resolve this issue by avoiding dependencies to be transferred transitively.

This can be done by adding “provided” in the scope of transitively occurring dependencies in their service’s parent pom.xml.

If that service’s code is not accessible, then we can add exclusion tag for that dependency in our service’s pom.xml. Regex for groupId and artifactId can be given.

<exclusions>
  <exclusion>
    <groupId>*</groupId>
    <artifactId>*</artifactId>
  </exclusion>
</exclusions>

An easy command which would help you to view all the dependencies of your project is:

 mvn dependency:tree

Adding dependencies explicitly which have been earlier provided by Lagom version 1.3:

Few of the dependencies, which were earlier provided by Lagom version 1.3. have been removed from Lagom version 1.4. So, now if you need to use those dependencies in your code, then they need to be explicitly added in the pom.xml.

Few of the example of such dependencies are:

• Spring framework
• Httpclient
• Javax.validation
• Hibernate.validation

 

I hope this blog will help you to migrate Lagom version of your service from 1.3.x to 1.4.x.

Thank you!!

 References:

https://www.lagomframework.com/documentation/1.4.x/java/Migration14.html