MyFaces CODI: your best friend for your CDI based projects
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:
– JSF (for 1.2 and 2.0)
– BV (Bean-Validation)
– Message (advanced I18N)
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 Orchestra.
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 day!
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 well.
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 CODI.
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.