Stock Apache Tomcat and Gradle on OpenShift

For my ongoing work on Tangram a wanted to use the RedHat OpenShift platform. In this post I'm going to outline the generic part of this which now is extracted as a Quickstart on github via https://github.com/mgoellnitz/openshift-tomcat-gradle-quickstart.
The requirements where the following: Build must be possible with Gradle and a plain Apache Tomcat webcontainer - not a JBoss Tomcat derivative - is needed. For the time being I still left out the option to use Jenkins, since the way to re-deploy on git-push OpenShift gives me, is quite usable.
So this results in the idea of a combination of the work of Shekhar Gulati at https://www.openshift.com/blogs/run-gradle-builds-on-openshift with the code at https://github.com/shekhargulati/gradle-openshift-quickstart and the tomcat Quickstart https://github.com/openshift-quickstart/openshift-tomcat-quickstart
Looking at the changes needed to use Gradle, I decided to integrate them manually and modify them along the way. Also the Tomcat Quickstart will not be used directly but serves as a template, since I don't want to pull the Apache Tomcat binaries into the git repository. As opposed to many other examples I came across, the installation of the RedHat cloud command line tools is completely left out. You might want to use them, but they are not needed for this example.
First of all I had to create an application (named "test") and had to take "DIY 0.1" as the type of application and clone the resulting repository.

git clone ssh://524e65...094@test-application.rhcloud.com/~/git/test.git/
cd test

This repository resembles the working directories of your application on OpenShift and is not just a development set of folders. So you will find some scripts here to interact with the infrastructure of OpenShift. These scripts have to be customized to fetch and configure Apache Tomcat and Gradle.
Now it's time to add script element to fetch the tool.

# .openshift/action_hooks/build:

# gradle build
set -x

DIR=`pwd`

# obtain tomcat
export TOMCAT_VERSION=7.0.61
if [ ! -f $OPENSHIFT_DATA_DIR/apache-tomcat-${TOMCAT_VERSION}.tar.gz ] ; then
  wget http://apache.../v${TOMCAT_VERSION}/bin/apache-tomcat-${TOMCAT_VERSION}.tar.gz
fi
if [ -f $OPENSHIFT_DATA_DIR/apache-tomcat-${TOMCAT_VERSION}.tar.gz ] ; then
  rm -rf tomcat
  tar xvzf $OPENSHIFT_DATA_DIR/apache-tomcat-${TOMCAT_VERSION}.tar.gz
  mv apache-tomcat-${TOMCAT_VERSION} tomcat
  cd $OPENSHIFT_DATA_DIR/tomcat
  rm -rf logs
  ln -s $OPENSHIFT_LOG_DIR logs
  cd $OPENSHIFT_DATA_DIR
fi

# obtain gradle
export GRADLE_VERSION=2.2.1
if [ ! -d $OPENSHIFT_DATA_DIR/gradle-${GRADLE_VERSION} ] ; then
  cd $OPENSHIFT_DATA_DIR
  wget http://services.gradle.org/distributions/gradle-${GRADLE_VERSION}-bin.zip
  unzip gradle-${GRADLE_VERSION}-bin.zip
  rm -f gradle-${GRADLE_VERSION}-bin.zip
fi

cd $DIR

cd $OPENSHIFT_REPO_DIR
export GRADLE_USER_HOME=${OPENSHIFT_DATA_DIR}gradle
export GRADLE_HOME=${OPENSHIFT_DATA_DIR}gradle-${GRADLE_VERSION}
export PATH=$GRADLE_HOME/bin:$PATH
if [ -f openshift-build.gradle ] ; then
 gradle --stacktrace -b build.gradle clean build
fi

Use at least version 2.2 of Gradle due to http://issues.gradle.org/browse/GRADLE-2871. Also Gradle needs some local directory on the target host.


# .openshift/action_hooks/pre_build:
 
# gradle storage dir build
set -x

if [ ! -d $OPENSHIFT_DATA_DIR/gradle ] ; then
  mkdir $OPENSHIFT_DATA_DIR/gradle
fi

The default stop action hook script contains some references on a ruby server and is missing a nice tomcat handling.


# .openshift/action_hooks/stop:
source $OPENSHIFT_CARTRIDGE_SDK_BASH

# The logic to stop your application should be put in this script.
if [ -z "$(ps -efww | grep tomcat | grep -v grep)" ] ; then
  client_result "Tomcat is already stopped"
else
  if [ -x $OPENSHIFT_DATA_DIR/tomcat/bin/shutdown.sh ] ; then
    $OPENSHIFT_DATA_DIR/tomcat/bin/shutdown.sh
  else
    kill `ps -efww | grep tomcat | grep -v grep | awk '{ print $2 }'` > /dev/null 2>&1
  fi
fi
exit 0


For safety reasons it might be a good idea to delete unexploded wars from the webapp directory of the tomcat installation


# .openshift/action_hooks/deploy:
set -x

# Addition:
for i in `ls $OPENSHIFT_DATA_DIR/tomcat/webapps/*.war`; do
  dn=`basename $i .war`
  echo "removing $dn"
  rm -rf $OPENSHIFT_DATA_DIR/tomcat/webapps/$dn
done

The start script has to be modified not to use ruby but the tomcat installation


# .openshift/action_hooks/start:
set -x
cp -rdp ${OPENSHIFT_REPO_DIR}/tomcat/conf/* ${OPENSHIFT_DATA_DIR}/tomcat/conf/
cp -rdp ${OPENSHIFT_REPO_DIR}/tomcat/lib/* ${OPENSHIFT_DATA_DIR}/tomcat/lib/
cp -rdp ${OPENSHIFT_REPO_DIR}/tomcat/webapps/* ${OPENSHIFT_DATA_DIR}/tomcat/webapps/cd $OPENSHIFT_DATA_DIR/tomcat
sed -ig 's/OPENSHIFT_DIY_IP/'$OPENSHIFT_DIY_IP'/g' conf/server.xml
sed -ig 's/OPENSHIFT_APP_DNS/'$OPENSHIFT_APP_DNS'/' conf/server.xml
bin/startup.sh

After these preparation steps it would be time to integrate your application by providing a build.gradle script in the root path and all the needed source files.
When using a custom domain, let this domain point to your Applications hostname via a DNS CNAME record. Then create an alias with your domain name for the application using the RedHat Cloud command line tool. (Or create the alias via the console web application) Don't forget to add this domain name to your server.xml override.

Google App Annoyance - aka Engine

Together with the missing support for the Servlet 3.0 specification in Google App Engine (and, yes, there are still too many situations were this specification level ist not available) we are reading from Google for their App Engine that classpath scanning is an issue on that platform and that this is one of the reasons that kept them from supporting this version of the servlet specification.
What I didn't read from Google is, that they noticed that the Servlet 3.0 version is (arguably) one of the most important steps since Java came to the web. There is no major framework in the Java world anymore not doing any classpath scanning right now. The mentioned Springframework I'm using is just one example.
After some five years of work with the Google App Engine and Java as the only language in use, I changed my mind and don't consider the App Engine as one of the first choices in cloud platforms for the Java world anymore.
And this is really just because of these two small issues.
Like very many others I'm using the Springframework - with component scan and thus with classpath scanning. Any first request to an instance take ages. But "first requests" are common in the cloud, where instances need to be shut down and brought up depending on load. And the cloud is what Google App Engine is about, isn't it?
I invested quite some effort to learn how to be fast on the first request while still using the Springframework and even developed my own stripped down, minimalistic Dependency Injection environment for the application setup (dinistiq) to only have the features I'm using at hand. But this all didn't help to make the end user experience satisfying. Things feel slow.
So in the end this all gave the push for Tangram to support that many new platforms, use the CI Features and Repositories at cloudbees, enjoy the command line access of OpenShift. This brought options of different frameworks and I learned much about cloud deployment and operation scenarios. So in that respect we should be thankful for the Google App Engine weakness.
But it still is the source of some level of complexity and number of artifacts flying around in what I call my dynamic web application framework Tangram. Also this currently renders Google App Engine the second best cloud platform for Java while still having great web based monitoring tools.

Neuer Frühling im Winter

Eventuell können wir die Diskussion ein wenig aufschieben, ob es nicht eigentlich kalendarisch noch Herbst wäre, aber es liegt nun einmal genug Schnee und trotzdem ist das Spring Framework in Version 3.2 herausgegeben worden.

Diesen Text könnte ich glatt auch einfach auf meine TODO Liste schreiben. Ein nettes, aber nicht aufregendes Update für das Spring Framework. Es ist ein extrem Umfangreiches, nicht immer komplett intuitiv und einfach zu benutzendes Framework, aber es tut einfach an so viele Stellen das, was man - mindestens im Web-Kontext - so braucht und wird von so vielen Menschen benutzt, daß ich für Tangram und fast alle kommerziellen Projekte irgendwo Spring im Einsatz habe.

Also sollte Tangram auch mal so schnell wie möglich den neuen Unterbau nutzen - wenn das mit Spring Security für den RDBMS-Bereich vereinbar ist. - Dort stehen wir im Moment noch auf dem "Development Release"  M1. Die Sanduhr tickt aber schon.

So richtig schön wird es, wenn man dann noch sieht, daß auch das Spring Framework in Sachen Source-Code-Verwaltung und Bau genau da angekommen ist, wo Tangram ganz klein und in der Ecke auch liegt: github und dem Build Tool gradle. Die Mavenfinsternis scheint langsam zu beginnen, wenn man auch in diesen Dimensionen sich auf das neuere Tool stützen kann.
Jetzt warte ich eigentlich nur noch darauf, daß die Google App Engine sich auf die Servlet Version 3 einschießt, damit man auch die qualitativ neuen Features dort gut nutzen kann.