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.

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.

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.

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.