Dienstag, 27. Oktober 2015

Dinistiq Version 0.5

The minimalistic Dependency Injection library for Java - Dinistiq - has been published in version 0.5.
This version still doesn't change the main outline of the project: It deals with a single - singleton - scope with a few extensions in a very small footprint library. The library does not introduce any custom tags but fully relies on a subset of the JSR330 definitions.
Despite its limited scope it still successfully executes the TCK and comes with a reasonable unit test coverage. These unit tests have been migrated to TestNG to be in sync with my other projects reflecting the license which better fits into the set of licenses of the used dependencies in this project.

Fixes

The once more extended test coverage after the migration to TestNG showed two bugs relating to class discovery. These have been fixed in this release.

Leaner Web Integration

Due to the use of older versions of the Servlet API, dinistiq had to use a central dispatcher servlet dispatching to other so called registerable servlets. This level of indirection has been complete removed. With dinistiq 0.5 the web integration is mostly rewritten now depending on the Servlet API version 3.1.
Sadly this also removes its URL pattern matching capabilities.
RegisterableServlet instances from the dinistiq scope are now registered with the Servlet container directly. They now present a number of Servlet specification compatible URL patterns (no regular expressions any more - sorry) and and the same ordering indicator as with previous releases.

Availability

Starting from release 0.4 dinistiq is available from the JCenter repository at

https://jcenter.bintray.com/dinistiq/

Latest snapshots are provided at

https://oss.jfrog.org/oss-snapshot-local/ 

There are already some 0.6-SNAPSHOTs available, but they don't present changes worth mentioning right now.

Migration

Take a look at your web.xml. If you see something like

  <servlet>
    <servlet-name>dinistiq</servlet-name>
    <servlet-class>dinistiq.web.DinistiqServlet</servlet-class>
  </servlet>
  <servlet-mapping>
    <servlet-name>dinistiq</servlet-name>
    <url-pattern>/s/*</url-pattern>
  </servlet-mapping>


simply remove it!
The RegisterableServlet interface has been change as mentioned. You will have to update you regular expressions to Servlet specification compatible URL patterns. Of your the respective method signature was changed from

    @Override
    public Set<String> getUriRegex() {
        Set<String> result = new HashSet<>();
        result.add("");
        result.add("/.*");
        return result;
    } // getUriRegex()

to

    @Override
    public Set<String> getUrlPatterns() {
        Set<String> result = new HashSet<>();
        result.add(source.getDispatcherPath()+"/");

        result.add(source.getDispatcherPath()+"/*");
        return result;
    } // getUrlPatterns()

Mind the missing regular expression syntax and that the full URI path has to be given.


Samstag, 3. Oktober 2015

Gradle Plugin for JDO, JPA, Ebean etc in Tangram grown up

As part of the Tangram framework project a set of build related things went into a plugin for the Gradle build tool.
Only in part this plugin is directly related to Tangram but offers some generic tools suitable for many projects.
The plugin does
  • Support underlying of WAR files into others (similar to overlays)
  • Minify CSS and JavaScript codes to be placed in WAR artifacts
  • Byte-code transform model classes for JDO, JPA, and Ebean ORM layers
Up to version 0.9 the plugin was more or less a collection of utility methods. It is now redesigned to do the same job transparently when appropriate and at the appropriate stage of the build process.

Usage

Just a few lines have to be added to your Gradle build script to use these add on functionality:

buildscript {
  repositories {
    jcenter()
  }
  dependencies {
    classpath 'tangram:gradle-plugin:1.0.0'
  }
}


apply plugin: 'tangram'

All of the following steps described here take place without any additional configuration.

Web application underlying

The plugin introduces a configuration named webapp for modules using the war plugin. Dependencies given for this configuration are extracted into the resulting war artifact.
This process is not really described well if called overlay so I call in underlying, since your web application's directory in fact is the overlay so the other archives referenced and included must be an underlying.
If your WAR relies on the contents of another pre-packaged or incomplete WAR, the contents of the latter will be copied into your resulting web application while you can override any file in this archive from your local web application contents directory.

Minification

When - again - used in a project also using the war plugin, all files included from the project directory will be checked for CSS and JavaScript file extensions. Matching files are minified using the YUI Compressor.
It is not possible to minify resource included from archive files. So contents from archives while being included in the resulting WAR cannot be minified. (We would expect WAR files to contain minified resources like WAR files generated using this plugin do.)

Handle Model Classes

When used with Java projects and when some data model classes are discovered, the plugin tries to prepare them for use with one of the ORM frameworks Java Data Objects (JDO), Java Persistence API (JPA), or Ebean.
The OR-Mappers require or recommend to apply byte-code transformations called "Enhancing" or "Weaving" to the class files for the data model related classes.
The plugin supports DataNucleus Access Platform (JDO and JPA), EBean, EclipseLink, Hibernate, and OpenJPA. All the calling options from the 0.9 version of the plugin have be removed and the APIs are auto-discovered so the whole process is now - except for logging output - transparent during build.

Version List

The plugin introduces a version object which collects some version strings for a number of libraries. This ensures that any project using the plugin can use these libraries with recent versions and version changes are applied in sync. The use of this part is optional and you have to explicitly use the versions in your build file since this cannot be applied transparently.
Some random examples:
dependencies {
  compile "org.pac4j:pac4j-openid:$versions.pac4j"

  compile ("org.apache.openjpa:openjpa:$versions.openjpa") {
    exclude group: 'asm'
  }

  compile "org.eclipse.persistence:org.eclipse.persistence.jpa:$versions.eclipselink"
  compile "$versions.persistence_api"

  compile "org.hibernate:hibernate-core:$versions.hibernate"
   
  compile "org.datanucleus:datanucleus-api-jpa:$versions.datanucleus"
  compile "org.dataucleus:datanucleus-core:$versions.datanucleus"
  compile "$versions.jdo_api"
  runtime "org.slf4j:slf4j-log4j12:$versions.slf4j"

  testCompile "junit:junit:$versions.junit"

  // your container will have this for you
  providedCompile "$versions.servlet_api"
  providedCompile "$versions.jsp_api"
}

Manual Mode

Of course it is still possible to call the methods performing the different tasks directly like described in the 0.9 plugin blog post.
Also it is possible to switch of the byte code transformation for JPA annotated classes by adding to your build file

// build.gradle: 
enhancer.enabled=false

in case this might be necessary e.g. to only use the other parts of the plugin.

Sonntag, 26. April 2015

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.

Mittwoch, 25. März 2015

Dinistiq Version 0.4

The minimalistic Dependency Injection library for Java Dinistiq has been published in version 0.4.
This version doesn't present anything specifically new. It still deals with a single - singleton - scope with a few extensions in a very small footprint library. The library does not introduce any custom tags but fully relies on an subset of the JSR330 definitions.
Despite its limited scope it still successfully executes the TCK and comes with a once more extended unit test coverage.

Availability Release

One of the main changes of this release is the availability of the release artifacts through the JCenter service of bintray. This renders the integration of Dinistiq even easier since you will most likely not need to add another repository or mirror to your infrastructure.
Dinistiq is in daily production use for some time now and will remain supported as long as there is not always a need for more feature complete solutions like Google Guice or the Springframework.

Next Steps

The versioneye service shows that Dinistiq is up to date with its dependencies with only one intentional exception. This release will be the last to support the Google App Engine through the use of outdated Servlet API versions.

Freitag, 5. Dezember 2014

Dinistiq Version 0.3

Dinistiq ist entstanden, weil es schneller zu implemtieren war, als die Integration anderer DI-Framework und Container in Tangram dauerte.
Da es dann eine Weile einfach alles tat, was notwendig war, wurde nur geringe Code-Optimierungen eingeführt.

Qualitätssicherung

Zu seinem ersten Geburtstag hat Dinistiq aber ein echte Upgrade verdient.
Seit August befindet es sich im produktiven Einsatz in einem Testframework zur Validierung der Einhaltung der Anforderungen für ein großes deutsches Medienportal, das auf einer neuen technischen Basis komplett reimplementiert wird.
Dabei sollte ein einfacher, effizienter, wartbarer und schlanker Technologiestack zu Einsatz kommen.
Die alternativen Stapelten Selenium, PHP und Shellskripte und waren nicht in der Lage, die angeforderten Varianten an Plattformen und Browsern mit Testfällen zusammenzuführen. Außerdem paßten sie natürlich nicht in die reine Java-Welt des Restes des Projektes.
Gleichzeitig sollten veraltete Techniken wie Maven natürlich ebenso außen vor bleiben.
Nun muß sich Dinistiq jeden Tag darum kümmern, hunderte von Testfällen mit jeweils unterschiedlichen Browsern und Zielplattformen durch Dependency Injection zusammenzuführen.

Qualitätssicherung

Dinistiq befindet sich nun täglich im Projekteinsatz und es ist nicht mehr hinnehmbar, wenn dabei genutzte Funktionen nicht zuverlässig nutzbar sind. Da Dinistiq mit dem Einsatz reift, sind dennoch häufige Snapshots nötig gewesen, sodaß ist einer verstärkten UnitTest Abdeckung und dem Einsatz von PMD zur Source-Code Kontrolle zwar nur ein Fehler befunden wurde, das Neu-Einführen von Fehlern aber von vorneherein úmgangen wurde.
Zur Generierung der Übersicht wird Jacoco eingesetzt.
Der Impuls war aber hier auch, daß der Einsatz in der Qualitätssicherung für ein ungleich größeres Projekt erfolgen sollte und so mußte sich Dinistiq als Testfeld für die angeforderten Qualitätsmaße an den Source-Code zur Verfügung stellen.
Bisher war dieser Schritt ein voller Erfolg und in jedem Falle viel einfacher umzusetzen als alle mir bekannten Alternativen wie Springframework, Google Guice, Weld, OpenWebBeans, die den Job sicherlich auch erledigen können.
Dafür gibt es heute den Stempel "0.3".

Details

Mit Version 0.3 ist auch das Standard Repository für die Artefakte gewandert und der CI Server ebenfalls. Dies ist nur der Tatsache geschuldet, daß Cloudbees sich aus dem Geschäft zum Jahresende zurückzieht.

Samstag, 30. August 2014

Tangram CoMA erwacht

Da ich nach einem langen Sommeurlaub nun wieder schwerpunktmäßig mit dem CoreMedia CMS zutun habe, habe ich mir auch im Tangram nach sehr langer Ruhe mal wieder die entsprechende Anbindung angesehen.

Ein altes Beispiele

Seit geraumer Zeit gibt es eine Beispielanwendung zum CoreMedia Adapter CoMA im Tangram Framework. Diese litt aber daran, daß das Aufsetzen der Umgebung dazu nicht ganz trivial war. Alleine schon deshalb konnte ich nicht soviel Energie in die Weiterentwicklung stecken.
Für diese Anwendung stehen Möglichkeiten von Tangram, Content einzugeben, nicht zur Verfügung, da der CoMA nur lesend arbeitet. Um dennoch Inhalte und ein paar Templates zum Zeigen zu bekommen, nutze ich die uralte Beispielanwendung MenuSite von CoreMedia selbst.
Man benötigt also zum Nutzen der Anwendung eine Datenbank, wie sie ein CoreMedia Content Server für die MenuSite angelegt und mit Daten befüllt hätte.
Bisher waren die Schritte, die nötig waren, um diese Datenbank aufzusetzen nur zur Ausführung beschrieben. Alle andere Beispiele kann man einfach bauen und starten.

Neue Server

Meine Experimente mit Gradle zum Zusammenbau von CoreMedia Softwarekomponenten ohne das bei mir nicht sehr beliebte Maven haben allerdings nun einen Stand erreicht, in dem man Skripte und kleine Workspaces präsentieren kann, mit denen man die benötigte Datenbank erstellen kann.
Die Content Management Server Webanwendung unter
https://github.com/mgoellnitz/cm-cms-webapp
und die Content Management Server Tools unter
https://github.com/mgoellnitz/cm-cms-tools
Die harte Nuß dabei war weniger der Server als das Tools Paket. Aber ohne die Tools konnte ich die Daten natürlich nicht in den Server importieren. Außerdem hat das von mir gewählte Tomcat Plugin für Gradle sich nicht von der freundlichen Seite gezeigt. Mittlerweile weiß ich, daß auch andere Anwendungen als der CoreMedia Content Server unter dem falsch zusammengestellten Classpath leiden.

Und alles ohne Maven

Die genaus Beschreibung findet sich im Beispiel Repository zu Tangram.

Sonntag, 17. August 2014

Tangram Release 0.9

Over the last year, Tangram has changed very much and does not look the same in all of its modules and options.

Persistence Options

The Tangram Dynamic Web Application Framework has been extended to support the Java Persistence API (JPA) and EBean as persistence layers in addition to the already available Java Data Objects solution. This greatly extends the number of options for platforms to use with Tangram.
The Tangram examples reflect this with the JDO/DataNucleus, JDO/Google App Engine, EBean, and JPA example where the later is switchable with tested API implementations for OpenJPA, EclipseLink, DataNucleus, and Hibernate.
The simple and more or less generic JDO editor now is a generic editor for all the storage solutions and built as a separate module. Except for Google App Engine this module can be left out if there is another solution available to get the content into the repository.

Dynamic Model Extenions

In addition to the Groovy implemented classes stored in the repository, which are used to extend the view and controller part of the application, you can now create JDO annotated classes which are immetiately usable as model classes in the repository. This option can only be presented for the JDO implementation.
To make the building of Tangram itself, any Tangram application, or even any application using byte-code transformation for JDO, JPA, and Ebean easier, a gradle plugin has been introduced. The examples and over blog entries illustrate the usage of this plugin.

IDE Integration

To be able to synchronize codes stored in the repository a separate FTP module has be introduced. Most IDE due to their strong PHP past support FTP better than any other protocol. CSS, JavaScript, Groovy codes can be imported and exported.

Generic Import and Export

Additionally and apart from the FTP module Tangram now contains a generic importer and exporter for the whole content stored in the repository. The XML representation can be used to transfer content between application using JPA, JDO, or EBean. IDs cannot be preserved.

Framework Independency

For the whole Tangram code the Springframework now is only an option to do the setup of the application by Spring's Dependency Injection IoC-Container and for the controller and view parts of the application.
Along this way it was easier to present a custom DI component, Dinistiq, than to use one of the available solutions. Tests have been done with Google Guice, TinyDI, and JSR-330. As of Tangram 0.9 none of these are more than experiments. Work on a Tangram JavaEE integration is also in an experimental stage and would require a major refactoring of some parts of Tangram, see other entries in this blog on the JavaEE topic.
It should now be fairly easy to do more experiments with other IoC/DI frameworks and containers or to integrate other web frameworks starting from the new plain servlet based solution.

Options

Tangram 0.9 has been tested, verified, or is even in production use on the following platforms: Google App Engine, run@CloudBees, OpenShift, and Standalone with Apache Tomcat using RDBMS or MongoDB.
The option matrix now looks like this:
Persistence: JDO, JPA, EBean
IoC: Springframework, Dinistiq
Security: Spring Security, Apache Shiro
Hosting: On Premise, OpenShift, Cloudbees, Google App Engine
Storage: RDBMS, No-SQL e.g. MongoDB, Files

Code Reduction

Tangram started as an idea to plug existing components together to form a web application with as little glue code as possible. Some of the ideas like object oriented templating though had to be coded explicitly. After this starting point the Tangram codes started growing and the 0.9 release got an additional design goal to stop this. Still some of the codes in Tangram duplicate functionality which would otherwise externally be available but avoids a depedency just to call one method. And there are still codes duplicates within Tangram where the different options e.g. for persistence might get a stronger common code base. In these areas it is still not clear if they will differentiate or grow together.

Outlook

The experiences with CapeDwarf showed the way into a Java EE module as an alternative to dinistiq, the Springframework, and the many tests with e.g. Google Guice. The not that encouraging experiences with the EBean ORM might lead to discontinued support for that module. Dinistiq will become more Java EE / CDI compatible and CDI without the full Java EE stack also seems to be an interesting option. Work on the generic import and export functions using XStream needs to be extended and easier integration of OpenID or OAuth outside of the Google App Engine is needed for many applications. Google App Engine with JPA is still on the list but not desperately needed.