You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 16 Next »

Table of Contents

Motivation

The Apache MyFaces Extensions CDI project (aka CODI) hosts portable extensions for Contexts and Dependency Injection (JSR 299) for the Java-Platform (SE and EE). MyFaces CODI is your best friend for CDI based projects. Like CDI itself CODI is focused on type-safety. It is a modularized and extensible framework. So it’s easy to choose the needed parts to facilitate the daily work in your project.

Hint

Neither CDI nor MyFaces CODI is bound to JEE 6, therefore you can choose the right time for using them in your Java 6+ applications.

Community (Support)

The Apache MyFaces community provides the usual community support. Please contact the dev or users mailing list.

External Professional Support

http://www.irian.at/myfaces_codi/

Unknown macro: {iframe}

Your browser does not support iframes

New ideas?

Please contact the MyFaces community or file a feature request in the issue tracker, if you have great ideas for new features.
(If you don't like to send an e-mail to a public mailing list you are welcome to contact one of the companies which support MyFaces CODI.)

Issue tracker

https://issues.apache.org/jira/browse/EXTCDI

Compatibility

Frameworks

MyFaces CODI is a portable CDI extension. That means it isn't an implementation of CDI. Therefore, you need a CDI implementation like Apache OpenWebBeans.
We suggest to use MyFaces CODI in combination with Apache OpenWebBeans (OWB) - it's a powerful duo which is already used in several real world projects. However, MyFaces CODI isn't bound to a specific project. We test it regularly in combination with other CDI implementations like Weld and in case of the JSF modules with Apache MyFaces-Core and Mojarra. If you face any problem in combination with one of the mentioned frameworks, please don't hesitate and contact the community. If you don't like to send an e-mail to a public mailing list you are welcome to contact one of the companies which support MyFaces CODI (see on top of this page). It's very important to get such reports!

Servers

We have tested MyFaces CODI with:

  • Tomcat 6 (6.0.24+)
  • Tomcat 7
  • Jetty 7.1.5+, 8.x
  • JBoss Application Server v7
  • Glassfish 3 (You might see a known JBoss-Weld Bug if you use EARs - this issue also affects other CDI extensions like Seam3)
    • (We recommend Glassfish v3.2+ since it's the most stable version we have tested.)
  • Weld v1.1.1+ recommended
  • JEE 5 Application-Servers + OWB (e.g. Weblogic 10.3)
  • SpringSource dm Server

Please contact us if you face any issues with the server of your choice.

Structure of CODI modules

Detailed information about CODI modules are available at CODI Modules - Overview and Setup

Every CODI module consists of an API and Impl module. The API JAR file of a module is required for compiling an application which uses CODI and provides the stable part of the framework. The Impl. module provides the default implementations for the API of the module. It isn't planned to provide multiple implementations, but the classes in the corresponding impl. JAR file might change occasionally and if it is possible they aren't exposed. However, in the documentation you will find some hints about useful classes provided by the impl. parts. You can use them on your own risk. You can expect that the mentioned classes won't change a lot, but we will do it if it makes sense for the framework. Impl. modules usually provide Service-Provider-Interfaces (SPIs) which allow to plug-in and customize your custom implementation via a type-safe config. Since the SPIs are located in the Impl. part they might change but we try to keep them as stable as possible.

  • No labels