MyFaces CODI Interview

MyFaces CODI: “your best friend for your CDI based projects”

Jessica Thornsby

We speak to MyFaces CODI project lead Gerhard Petracek, on the project.

Apache MyFaces Extensions CDI (MyFaces CODI) has just announced
its first release. In this interview, JAXenter
speaks to Gerhard Petracek, project lead of MyFaces CODI, to find
out more about the project…….

JAXenter: What is the MyFaces CODI project?

Gerhard Petracek: The original idea was to
create portable CDI extensions which are similar to MyFaces
Orchestra. CDI (JSR 299 – Context and Dependency Injection) is a
new specification for the Java platform (SE and EE) which provides
a powerful SPI for creating such portable extensions. Quite soon we
realized that CDI offers really great mechanisms which allow us to
provide more advanced features. Now the main mission of CODI has
evolved to provide a toolbox for CDI based Java projects. The name
is pronounced like the common nickname which should emphasise that
MyFaces CODI is your best friend for your CDI based projects.
MyFaces CODI is modularized (but you can also use an all-in-one
bundle), type-safe, customizable, extensible, easy to use and last
but not least – it’s well documented.

The first release provides the following modules:
– Core
– JSF (for 1.2 and 2.0)
– BV (Bean-Validation)
– Message (advanced I18N)
– Scripting

Most parts of CODI are type-safe. Also the optional (!)
configuration is type-safe! Furthermore, CODI allows users to
improve the type-safety of JSF applications – e.g. based on the
type-safe view-configs it’s easy to use type-safe navigation and a
lot of other new features.

Moreover, CODI also contains a rich set of SPIs which allows
users to customize the standard behaviour. Since CODI relies on
standard CDI mechanisms, users don’t have to learn a proprietary
configuration format.

Out-of-the-box CODI already provides a rich set of features.
However, if you have special requirements which are not supported
by the default implementation, it is easy for users to implement
custom behaviour based on the standard CDI concepts. A list of
available add-ons is hosted on the project’s Wiki.

JAXenter: CODI is inspired by MyFaces
Orchestra. How does the Apache MyFaces CODI
project, build on MyFaces Orchestra?

Gerhard Petracek: The MyFaces Orchestra team
did a really great job! We are using the conversation concepts
provided by Orchestra very extensively in a lot of successful
Spring based projects and they improve the productivity a lot. If
you have a framework which you would really miss if you switch to a
new platform, you have to ensure that there is an alternative for
it. CDI is a great specification, however, if you are used to the
conversation concepts provided by Orchestra, you (might) get a
problem with standard CDI conversations. So at the beginning our
mission was to create a portable CDI extension which provides
similar concepts for CDI. Instead of just cloning the existing API,
we redesigned it from scratch. The basic conversation concepts are
the same, however, we took the chance to include some improvements.
For example we introduced a new scope (@WindowScoped), a rich SPI
which allows users to solve advanced use-cases and a lot of other
new concepts. Beside grouped conversations we included a lot of new
and great features in our toolbox which are not available in

Before we published the first release, we tested CODI in
real-world middle to large sized projects. That means we have a
framework which is already used by existing applications and we had
the chance to stabilize the implementation. Some of these projects
are already in production and serve millions of page requests per

Apart from that, we also skipped some features provided by
Orchestra like the persistence management. It depends on the
community, if we see the skipped features e.g. as add-ons. That is
basically a very important message. We should not forget that
MyFaces is a community centric project. So we appreciate the
feedback of our great community! To be even more open we created
GIT and Mercurial mirrors. So it is very easy for users to create prototypes for new features and to share
their ideas

JAXenter: CDI already provides conversations,
so why does the developer need new scopes?

Gerhard Petracek: Standard CDI conversations
are more like a session per window. We
experimented a lot with them. The problem with the standard CDI
conversation scope is that we immediately found some important
use-cases which just do not work or at least don´t work very

CODI conversations are more fine-grained. Per default every bean
is “un-grouped” and thus it exists in a separated conversation
within a window. This means that you have multiple conversations in
parallel which allow a fine-grained memory-management. Furthermore,
CODI provides a SPI which allows more advanced memory management
use-cases. Moreover, standard conversations have to be started
manually whereas CODI conversations are started automatically as
soon as you access a bean. Therefore, CODI conversations have e.g.
the advantage that conversation scoped beans won’t have to be
created over and over again in case of a failed conversion or
validation process. If you don’t need a conversation any more, you
can close it (or even all existing conversations) immediately.
Compared to CODI conversations, standard CDI conversations will be
closed after the rendering process which may lead to issues
(depending on the page-flow of the application). If you really need
this last feature of standard CDI conversations, you can use an
existing CODI add-on hosted by the os890 project.
Such add-ons also demonstrate the powerful extensibility of

JAXenter: MyFaces CODI replaces Orchestra’s
conversation names, with conversation groups. What is the benefit
of this for the developer?

Gerhard Petracek: At the time Orchestra was
developed it had to use (Spring) XML
configurations. So they used Strings as names for conversation
groups. If you think about it, it is quite easy at the beginning,
but it might get quite hard for users to refactor or even find
beans of a conversation-group. Basically we kept the concept – you
can group beans for scoping them in the same conversation. However,
in CODI you can use e.g. an (empty) interface as type-safe
conversation group. So you cannot mistype a group and you can
easily find and refactor beans which belong to the same
conversation-group without special IDE support. Type-safety is also
an important concept of other new specifications and frameworks
like Bean-Validation and MyFaces ExtVal.

comments powered by Disqus