JAX London 2014: A retrospective
Closing the Gaps

Introducing Apache Deltaspike


Gerhard Petracek and Jason Porter tell us about CDI portable extension project Apache Deltaspike, from its inception to its current state on the road towards a first stable version

This article traces the development of Apache DeltaSpike from the roots to its present status. This rapidly-growing project is surrounded by a very active team of developers whose goal is to create a thoroughly tested and stable version 1.0 that is compatible with all major server platforms which support CDI.

In 2004 the world of J2EE started to change with the rise of an alternative framework. Version 1.0 of the Spring framework was released and it became easier to implement enterprise level applications. Spring gained a lot of popularity over time and it also influenced Java EE.

With the next version, Java EE focused on “Ease of Development” as well technical concerns of the growing technical complexities required in applications. Even though Java EE became much simpler, there were still some loose ends. Therefore version 1.0 of JBoss Seam was released in 2006. It provided a toolbox to fix some of the shortcomings.

At the same time, the Spring framework provided its own approach for integrating several parts of Java EE in a different manner. About one year later, JBoss Seam version 2.0 was released and the MyFaces community released version 1.0 of a new Spring extension named Apache MyFaces Orchestra. MyFaces Orchestra introduced scopes which differed a lot from what was available so far, but the basic purpose was similar to JBoss Seam. JSF users who preferred the Spring framework got a powerful tool with MyFaces Orchestra, and JSF users who were in favor of Java EE 5 could use the Seam framework as a convenient toolbox. Later on, several dependency injection frameworks inspired a new Java EE specification with the name Contexts and Dependency Injection for Java EE (aka CDI) which was released in 2009 as a part of Java EE 6. In parallel also the Spring framework moved in a very similar direction. Both camps solve the same problems, but there are still significant differences.

The rise of CDI extensions

In contrast to the Spring framework, CDI is available out-of-the-box in Java EE 6+ application servers and therefore it’s very important to have sufficient standardized hooks for additional frameworks to use them independent of the details of an application server to avoid vendor lock-in. Java EE 6 is the first Java EE specification which doesn’t need an additional framework for painless usage or for replacing manual integrations of different parts of the platform. At least that’s a common message of some community members. Java EE 6 is closer to this statement than the former versions.

However, it turns out the real world isn’t that shiny. A lot of new innovations still happen in the Open Source space first and some features might even be too special to be included into a specification. Therefore it was intended to provide a rich set of extension points from the very beginning. That allows to keep specifications in general and CDI in particular consistent and simple without restricting custom approaches and mechanisms.

As mentioned earlier, CDI is provided out-of-the-box by Java EE 6+ servers and therefore a very important aspect of CDI extensions is portability which allows them to be used seamlessly in combination with all implementations of the CDI specification. Apache OpenWebBeans and JBoss Weld are such CDI implementations and they allow to use CDI even with plain Java SE. Therefore, neither CDI nor portable CDI extensions are restricted to Java EE. That allows to create different types of CDI extensions. Apache DeltaSpike is such a collection of portable CDI extensions. To understand the roots of DeltaSpike it’s important to look at two famous portable CDI extensions – JBoss Seam3 and Apache MyFaces ExtCDI (aka MyFaces CODI).

JBoss Seam3

Seam 3 started shortly after JSR 299 completed. The goal of Seam 3 was not to be a complete migration of all things from Seam 2, but it provides a rich toolbox for building standards-based web applications tailored for traditional and cloud deployments. Certainly some ideas came from Seam 2, but many more came from the community. Unlike the starting of Seam 1 and 2, Seam 3 did not simply want to improve JSF support, but to unite many technologies with CDI.

Many of the modules developed in Seam 3 demonstrate this such as ‘Mail’, ‘JMS’, ‘JCR’, ‘Reports’ and ‘Spring’-Integration. All of these modules came from the community as a hole was discovered while using the technologies and seeking a more unified and simpler approach for developers. Other areas in developer productivity were explored in Seam 3 such as type safe logging in Solder, exception handling also in Solder though formerly Seam Catch, XML configuration via Seam Config, now in Solder.

Apache MyFaces CODI

Similar to JBoss Seam, MyFaces Orchestra provided better scopes for JSF applications as well as an optional integration with the Java Persistence API (JPA) to allow the usage of an extended persistence context. Originally MyFaces CODI was started to port some concepts provided by MyFaces Orchestra to a portable CDI extension. However, since CDI endorses type-safe dependency injection, MyFaces CODI was designed from scratch and only some of the basic and successful concepts of MyFaces Orchestra were used as basis for some features of MyFaces CODI.

The most important qualities of MyFaces CODI, which attracted several users even before the release of version 1.0, are the reality check of existing concepts in combination with innovative new mechanisms, the support for almost all major Java EE 5/6 application servers, an easy but powerful API and SPI as well as a fast and solid implementation, and last but not least, a great community.

MyFaces CODI doesn’t enforce a specific programming model. Instead it relies on CDI concepts as much as possible and users just use what they need in addition. They can even replace parts of MyFaces CODI with custom implementations which get picked up by the rest of the framework or deactivate parts completely to improve the performance even further. Like CDI itself, MyFaces CODI relies on type-safety as much as possible. This allows use of standard Java support in existing Java IDEs without the need for special IDE Add-ons. In addition, it avoids mistakes like typos and therefore allows an easier refactoring and maintenance process.

The Future – Apache DeltaSpike

Since CDI encourages the usage of portable CDI extensions, users have to look at several accredited portable CDI extensions like JBoss Seam3 and Apache MyFaces CODI as well as several smaller projects and blog entries about implementing such extensions with varying quality. Several communities of CDI extensions came up with similar ideas and features. Most of the time it is possible to mix multiple portable CDI extensions without problems.

However, usually there is no out-of-the-box optimization across different extension-projects, and to combine them sometimes requires a detailed knowledge about the projects. For example, it is not difficult to use Seam3 in combination with MyFaces CODI, but both have different security concepts which are not aware of each other out-of-the-box. Instead of implementing and documenting the corresponding adapters for the major extensions, a large part of the community decided to start a shared CDI extensions project developed and maintained by the community. The Apache Software Foundation was chosen due to its reputation concerning community-driven and vendor-independent projects.

Amongst many others, the project management committee of Apache MyFaces was excited about this idea, and the lead developers of MyFaces CODI helped to draft a proposal for such a new Apache project. The hardest part was the name for the project. After some discussions the upcoming community agreed on the intermediate name “DeltaSpike”. With this name, the community entered the Apache Incubator, which is the entry point for all new Apache projects. Before the project leaves the incubator and graduates to an Apache top level project, the community will vote a final project-name. The initial committers of the DeltaSpike community are representatives of several existing CDI communities which joined the effort from the very beginning.

Aside from some other important tasks, the community merges features of the participating extension projects, adds new features and grows a community before DeltaSpike becomes a top level project and leaves the Apache Incubator. Before a feature gets added to DeltaSpike it is discussed by the community.

Progressing fast

Two months after the first e-mail on the mailing list, DeltaSpike v0.1 incubating was announced. With this first step, the community started to merge features of Apache MyFaces CODI-Core and JBoss Solder which is a central part of Seam3. Every DeltaSpike release is well tested on multiple containers and many real world projects. Nonetheless it’s expected that even APIs will change until version 1.0 based on the feedback of the community and new features and bug fixes will be added quickly.

In the next release, the community will add further DeltaSpike-Core features as well as new modules. Besides reviewing, discussing and adding features to DeltaSpike, the community is also working on a great documentation, examples, as well as a test-suite which should ensure true and tested portability across different environments.

UPDATE – As this article was written in February, 0.2 has already landed as linked above. This recent interview with Red Hat’s Pete Muir gives further details on where DeltaSpike is at, and its plans to become the de-facto Java CDI extension hub, as Seam merges into it. The Apache Deltaspike are currently working towards v0.3 (CM)

Join the Community

There are already several very active community members who enjoy the great cooperation. At Apache the most important part of a project is its community. Especially users who are not familiar with Open-Source communities in general or Apache projects in particular sometimes do not know how to get involved. Therefore the DeltaSpike community is working on a short overview of different types of involvement and the corresponding steps. Everybody is very welcome to get in touch with the community and every question which is not covered by the Wiki is very welcome to improve the Wiki and therefore the experience for new users.

It’s important to understand that everybody is welcome to join the discussions or to provide feedback to improve DeltaSpike step by step. It makes sense to join the effort as soon as possible because the community moves fast and has agreed on releasing early and often.

The new era – DeltaSpike v1.0 and beyond

After merging the best features and introducing new concepts, you can expect that the result is better than the original parts. An example which is available since v0.1-incubating is @Exclude. In case of @Exclude the community merged @Veto from Solder with @ExpressionActivated and @ProjectStageActivated of MyFaces CODI. Originally, the discussion was about more expressive names for all of those annotations, and the result was a single annotation called @Exclude with the features of the original annotations. This means the final version is more expressive and easier for users without losing functionality. The listings 1-3 show independent beans with the new annotation. The result might sound obvious, but it took some time and a lot of e-mails to find the right name which allowed to merge the functionality and preserve the expressiveness.

Listing 1: Service Implementation for project-stage ‘Unit Test’
@Exclude(exceptIfProjectStage = ProjectStage.UnitTest.class)
public class TestServiceMockImpl implements Service
Listing 2: Service implementation for a database different from type ‘prodDB’
Listing 2 - start
@Exclude(onExpression = "db_type==prodDB")
public class DevServiceMockImpl implements Service
Listing 3: Utility class which shouldn’t be a CDI bean
Listing 3 - start
public class CustomUtilClass


As mentioned earlier, DeltaSpike will release early and often. So 0.1-incubating doesn’t contain that many features for application developers, but DeltaSpike grows rapidly and besides DeltaSpike-Core, the community is currently working on two new modules which will are part of the 0.2 release.

Right now all modules can be used even in Java SE applications. After finishing the most important modules like Security, I18n, Exception handling which can be used in Java SE applications as well, the community plans to start with several integration modules for Java EE technologies like JSF, JPA, REST, JMS as well as other frameworks like Spring and Quartz.

The goal regarding JBoss Seam3 and Apache MyFaces CODI is to add as much as the majority can agree on. Since the community is optimistic to add and/or merge most features in/into DeltaSpike, it is expected to be easy for users of the original extension projects to migrate to DeltaSpike. Instead of using workarounds for the migration, users are invited to join the effort early and share use cases which might not be supported at the time they try to switch to the corresponding module of DeltaSpike. In the end they should see an even better approach they can use.

Version 1.0 should be fast, thoroughly tested, very stable and compatible with all major server platforms which support CDI. The DeltaSpike team is already very active, and all of us are confident that it will grow as fast as DeltaSpike itself to reach the goal of a stable, reliable and truly portable CDI extension and even more important: a great community.


This article first appeared in Java Tech Journal: CDI in March. You can find more of that issue here.

Gerhard Petracek is Apache MyFaces committer and PMC chair; Apache OpenWebBeans committer and PMC member; Apache DeltaSpike committer, PPMC member and mentor; Apache member; Bean-Validation expert group member and a founder of Apache MyFaces Extensions Validator, Apache MyFaces CODI and Apache DeltaSpike. At IRIAN Solutions Gerhard is responsible for Java-EE trainings and the development of modern web-applications for customers such as Credit-Suisse. Furthermore, he holds lectures at an Austrian University of Applied Sciences and is the author of several articles on JSF and Java-EE.
comments powered by Disqus