Montag, 7. November 2016

Dinistiq Version 0.6

The minimalistic Dependency Injection library for Java - Dinistiq - has been published in version 0.6 some time ago.
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.
Called the qualifier release, besides dealing with qualifiers this release updates the dependencies, dinistiq relies on.

Qualifiers Introduced

Despite the fact that Dinistiq passes the TCK for JSR330, it lacked handling of qualifiers following the standard. This has been fixed with this release at the account of performance of the container.
None of my projects uses this feature, so the implementation fully relies on the TCK run integrated into the CI builds and the others dinistiq available. These tests of course have again been extended.


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

Latest snapshots are provided at 

There are already some 0.7-SNAPSHOTs available, which reduce the number of dependencies needed by Dinistiq.


There are no special migration steps necessary for existing application.

Sonntag, 8. Mai 2016

Java 8 on OpenShift

For some time now - supported by many articles I read on the web - I thought it was a fact that

OpenShift does not support Java 8

While the OpenShift Platform as a Service environment - even some time after Java 7 left the public support track - doesn't really push you to use Java 8, it well supports it in the sense that it's simply there - but just not the default.
Of course this has been mentioned before, but there are too many recent post around stating the opposite.

OpenShift has Java 8 in Place

When you stop reading articles and just dig around in the system, you can very quickly come to the point where you see, that OpenShift has numerous Java Development Kits installed and that the default is set by Linux standard means: /etc/alternatives.
So you don't have to download it, invest space and update it regularly to the current version. This is handled by OpenShift.

Wide Choice of JDKs

The /usr/lib/jvm folder has everything you might need - JDK-wise - and a simple scriptlet in your deployment will bring you to the needed JDK:

export JAVA_HOME=`find /usr/lib/jvm -name "$JAVA_VERSION"`
if [ -z JAVA_HOME ] ; then

So, no need to stay away from Java 8 because of something related to OpenShift (anymore).

Prepared Quickstart for Java 8, Gradle, and Tomcat

For the users of Gradle and Tomcat I updated this in my quickstart on based on the DIY cartridge.

Freitag, 6. Mai 2016

Tangram Release 1.1

The 1.1 release is a consolidation release removing outdated stuff leaving
room for latest versions of the used libraries and modules and providing some
polishing in the existing feature set.

Beyond the App Engine

The sources and release notes can be found on, the binaries again reside on JCenter. This release includes some notable overdue dependency updates like
  • Servlet 3.1 API now included
  • JSP 2.1 now included
  • DataNucleus updated to 4.1
  • dinistiq updated to 0.5
To allow this, it leaves out the Google App Engine support.

Gretty Plugin

Since not only the Google App Engine has a defect with old releases of Java
Web APIs but also Gradle has a obsolete Jetty plugin with an old version of
Jetty, all examples have been migrated to Gretty which is now the preferred container integration and even application packaging option.

Morphia Support

Latest Tangram applications always used Mongo DB as the storage backend with either JPA or JDO as the API. If you don't need the API abstraction or want an even leaner storage integration (before that DataNucleus JDO and EBean had the smallest footprint) you now can start using the "Mongo DB only Mapping" Morphia.

Markdown Support

Up to now every property using char[] for getters and setters was handled as structured text. It was edited as an HTML fragment (p or div) using the CKEditor.
Starting with this release, every property using org.tangram.content.Markdown for the getters and setters is handled through the CodeMirror editor as Markdown syntax. It is transformed to HTML in rendering.
Also templates can now be in Markdown syntax whenever appropriate while also here the output is transformed to HTML before passing the templates to the other layers of Tangram.

Taking Care of the Modification Date and Time

If you need to track the modification time of an object through the Tangram editor module or the ftp service, you can now do so and the standard storage backed classes of Tangram now do so.

File Restart Cache

The restart caches used for faster restarting of the application with data which should not be changing between sessions of the application now only have to be cleared manually on error conditions but not on changes of the application any more.

Exporting and Importing

The export and import features of Tangram are now strictly symmetrical: Full content export and import  - more or less independent of the storage flavour in use - and a code exporter and importer for the sources stored in the repository.

Fat JARs

Additionally it is now possible to leave out the "war" dependencies since
resources like templates can be placed in the respective JARs.

Extended testing

Tangram now for the first time has a decent test coverage. While there still
is room for more in depth testing of many functions, we now can put more trust
into the single snapshot builds. This was quite important since most Tangram
applications not residing on the Google App Engine already migrated to the 1.1