With Kotlin and Spring Boot to the Clouds

0. Overview

This posting is based on a quick customer demo that I did the other week. It demonstrates running Kotlin code in different public clouds. To be more precise: We use Kotlin together with Spring Boot to create a somehow minimalistic REST-like application that is running on multiple, load balanced instances on AWS Beanstalk or Oracle ACCS.

1. Kotlin

Kotlin is one of the upcoming, trendy JVM-based languages. It’s syntax is close to Java, but just sometimes more convenient. The language is backed by two industry giants: Pivotal announced support forSpring and Google officially supports Android development with Kotlin.

The Kotlin language follows the Java coding conventions, but makes the semicolon mostly optional (great!) and adds null-pointer safety (you never had problem with this in Java, did you?) and string interpolation on top of that. Although Kotlin packages are same as in Java in reverse order, in Kotlin package names don’t have to match to folder structure (great!). Interesting enough, most Kotlin control structures are expressions.

2. Spring Boot

We will use Kotlin together with Spring Boot in this posting.

Project Creation

For the purpose of this demo we will create the smallest possible application that is still helpful to learn about the synergy of Kotlin, Spring Boot and cloud. To get started, we create a maven project  for Spring Boot with the spring.io initializer.

The project will contain an empty Spring Boot application and the maven pom file amongst others.

Add a Controller

To get some meaningful output we add another Kotlin class: a controller with three functions. Did you know, the “fun” in Kotlin is for function?

  1. the hello(World) function that simply echoes a name.
  2. a func that shows how to access java.util.Date from Java and returns the time.
  3. a info func that show a bit of load balancing magic when deployed on ACCS.

Build the Project

We can build the project with mvn package from the command-line (or from the IDE, as shown in the web cast).

IDE Support for Kotlin

Being developed by Jetbrains, Intellij offers great support for Kotlin. In this webcast I simply use Netbeans.

 

3 Kotlin in the Clouds

This little demo is more real life than you might think. I will show you to run Kotlin in two different clouds. These days I see multiple clouds at my customers usually. Simply choose the one you like most.

3.a ACCS

ACCS is a Oracle Public Cloud PaaS service that provides several language runtimes. ACCS is based on Docker containers, but don’t worry, you won’t see any of them. With ACCS you can easily deploy Java, Java EE, as well as Python, Ruby, NodeJS and even Go code. Also it supports spinning up multiple instances with load balancing.

Deploying a .jar file on ACCS is as straight forward as it gets:

  1. zip it.
  2. upload it.
  3. run it.

However, there is one more thing: to successfully run the .jar file we need to add a manifest.json file that contains the exact command how the jar file will be started in the Java container. It should be all obvious watching the webcast. Check my other posting to learn about ACCS and Java EE.

3.b Beanstalk

The AWS Beanstalk deployment isn’t more complicated than the ACCS one. Actually even the manifest.json file can be omitted. Beanstalk implicitly understands how to run a .jar file (which of course is easy in most cases: java -jar demo.jar). So all you need to do is upload to Beanstalk. However with Beanstalk we have to make sure to include a SERVER_PORT variable and set its value to 5000. This is required since Beanstalk is internally listening to port 5000 but Spring Boot uses 8080.

5. Web cast

I created a web cast for you with all the details.

6. Ressources

Some additional resources that you might find useful:

  1. Kotlin language
  2. Try Kotlin online
  3. Spring Initalizer
  4. Get started with ACCS
  5. Access the demo code from github. TO DO.
  6. AWS Beanstalk

 

 

OSB 12c (12.2.1.2) More Maven Issues and Solutions

Existing Bugs and Issues with Maven and OSB 12.2.1.2 and How to Fix Them

It is a well known fact that Maven in OSB 12.2.1.1 came with glitches that required manual fixes as described in Robert Patrick’s blog posting and in the Oracle support notes Doc ID 2186338.1. However, this article is centered around the latest OSB 12.2.1.2, its particular Maven issues and how to fix them. Same as version OSB 12.2.1.1 also 12.2.1.2 suffers from various maven glitches, however in a more subtle way.

[Note, that I usually don’t post references to MOS, since not everybody has access to it. Anyway, if you cannot access to Doc ID 2186338.1 don’t worry. It basically describes what Robert writes about in his blog. In addition it recommends actually not to fix it manually, but instead wait for a patch. I actually I agree. Also note that as of OSB 12.2.1.2 this issue is not marked as fixed although the behavior of the newest version is different.]

The current situation with OSB 12.2.1.2 and Maven is “interesting”, to put it mildly:

  • mvn with OSB 12.2.1.2 and the maven push plugin only will not work out of the box. This means the official documentation won’t help you in this case. The good news – despite the fact that mvn with OSB 12.2.1.2 is not working correctly – is that it is rather easy to fix manually (see below, Fix 1: Maven with OSB 12.2.1.2 and the mvn push plugin).
  • Also mvn with OSB 12.2.1.2 and maven.oracle.com will not work (as of Jan 7, 2017). Since the required .pom and .jar files are pulled over from maven.oracle.com and several of them are missing it is obviously not easy to fix it yourself.
  • Here comes the crazy part (well, crazy on an IT scale): if you configure both, i.e. first use the OSB Maven plugin to push from an OSB 12.2.1.2 ORACLE_HOME into the .m2 repository, and then in addition configure the maven.oracle.com repository, then it is done twice. Yet then also both issues cancel each other out.

 

Here are the fixes, as promised

Fix 1:Maven with OSB 12.2.1.2 and the mvn push plugin

a) easy manual fix, updating two lines in two files:

After usign the push plugin, in .m2 Repository, e.g. D:\Users\frank\.m2\repository\com\oracle\servicebus\sbar-system-common\12.2.1-2-0 change the file sbar-system-common-12.2.1.2.pom as follows:

under

    <parent>
         <groupId>com.oracle.maven</groupId>
         <artifactId>oracle-common</artifactId>
         <version>12.2.1-1-0</version>
     </parent>

change the version tag to <version>12.2.1-2-0</version>

also for the file sbar-project-common-12.2.1.2.pom in the directory
.m2\repository\com\oracle\servicebus\sbar-project-common\12.2.1-2-0 change the version number the same way.

b.) Install patch 22392646

This is the second, alternative option to fix the issue. Install patch 22392646 from My Oracle Support. After a lengthy and tiring discussion I had with support it is now also applicable to OSB 12.2.1.2. – voilà! Depending on your provisioning approach this might be the easier fix, but actually you could just copy over the files (or even run sed on those two files).

 

Issue 2: Maven with OSB 12.2.1.2 and the maven.oracle.com

There is no known fix at the moment, maven.oracle.com is missing a whole lot of files (again) and also some of those delivered are wrong again. Bug 23698828 describes a very similar issue, yet reports it as fixed for 12.2.1.1. Oracle support knows about it, so let’s hope it will be fixed soon in maven.oracle.com. I will keep you posted, promised.

Update: After the first round with support their “solution” did not work. The issue is still not fixed. If you think about it for a second, how hard can it be to push a patched .m2 repo to maven.oracle.com? Stay tuned 🙂

To conclude

You are lucky if you simply retyped all the instructions available and configured both ways to use Maven with OSB 12.2.1.2 (although I somehow guess you would have not read this article then).

As soon as you follow a clear path and either go for the push plugin on a machine with OSB installed, or maven.oracle.com on a build server without an OSB installation, you will run into issues. It is obvious that Oracle would do good with automatically testing this functionality for future releases. Not being able to browse the maven.oracle.com repo makes it more difficult for customers to debug those issues, so it might be a good idea to use a local proxy / cache.

Let me know your feedback!