Closing the Gaps

Introducing Apache Deltaspike

GerhardPetracek
Apache-Logo2

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’
@Alternative
@Exclude(exceptIfProjectStage = ProjectStage.UnitTest.class)
public class TestServiceMockImpl implements Service
{
 //...
}
Listing 2:
Service implementation for a database different from type
‘prodDB’
Listing 2 - start
@Alternative
@Exclude(onExpression = "db_type==prodDB")
public class DevServiceMockImpl implements Service
{
 //...
}
Listing 3:
Utility class which shouldn’t be a CDI bean
Listing 3 - start
@Exclude
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.

Author
GerhardPetracek
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
comments powered by Disqus