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.

Why use JSR330 Dependency Injection annotations

I rather apologise to introduce another Dependency Injection Container for the Java world - dinistiq - a very minimalistic approach to the topic. It turned out to be easier to implement another one, than to use others listed here. Limited in features, easy to use, and still more configurable than other options I could think of. After some months of use, I now can invite other users to take a look at it and try it in their own projects.

Also this text gives you a "why" on the use of the JSR 330 annotations for Dependency Injection. It simply makes your code even more reusable in case your development or deployment environment changes.

Since tangram is much more about glueing together proven existing software components and frameworks than writing code, I felt the need to check if the existing code base was really fully dependent on the Spring Framework.

Despite the fact that spring more or less in many ways does what I need, it sometimes feels a bit bloated and does too much magic I don't understand in detail (which I still had to learn when debugging things). So I tried to isolate the spring code during the tangram 0.9 work and present at least a second solution for all the things I did with spring so far.

For tangram spring does three things

• Dependency Injection to plug the whole application together
• support a decent view layer with JSP and Apache Velocity views
• A concise way to map http requests to code - controller classes or methods

So I took a look at other view frameworks like Vaadin, GWT, Apache Wicket, Play, Struts, JSF/JEE, Stripes. Right at the moment I think Vaading, GWT, Wicket, and Play are no really good fit for tangram, Struts in my eyes is a fading technology, and only JSF/JEE is an obvious option. With Java Server Faces I only had unsatisfying project experiences and the rest of JEE goes for plain Servlet. So tangram had to be provided with a plain Servlet way of doing the view layer.

Since the modularity of tangram was achieved by the Spring way of plugging components together with Dependency Injection, the first thing to do was, to mark the generic components in a spring independent way and to look at the other options for the Dependency Injection part. Only then it would be possible to replace the spring view layer with a Servlet view layer during the startup and wire-up of the application.

So the list of relevant DI frameworks gets shortened to those supporting the generic Dependency Injection annotations from JSR330 which are intended for JEE and can e.g. also be used with Google Guice and the Spring Framework alike.

From the reading Google Guice seemed to be a good alternative for the proof of concept phase, but it took me that much work to get something to run with it (not everything can be plugged together programmatically in my case), that I came out faster with my own Dependency Injection Container. Rather minimalistic and only suited for the setup of components.

Its advantage over Guice is that it's smaller and easier configurable with properties files. Weeks later I discovered TinyDI as another option. While this container seems to be a lot cleverer about the search of annotated classes it seems to lack the needed option of extending the configuration aspects from the annotations with properties files - defaults and overridden values and references.

So right at the moment I still don't have a running tangram application but all of the tangram framework now can be used with dinistiq. This example shows that now over 90% of the classes of tangram are free of direct dependencies to the Spring Framework while still taking advantage of its features and runtime environment. The code definitely got cleaner and more reusable.