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.

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/

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!

The following frameworks are listed explicitly because they are spec. implementations of an API used by CODI or they also integrate with the same spec/s (e.g. JSF component libraries).
Other libs which don't implement APIs used by CODI or don't extend them should be compatible by definition.

We have tested MyFaces CODI with:

• CDI implementations
  • Apache OpenWebBeans
  • JBoss Weld
• JSF implementations
  • Apache MyFaces Core (1.2.x - 2.x)
  • Oracle Mojarra (1.2.x - 2.x)
• Component libraries
  • Core Components
  • Apache MyFaces Tomahawk
  • Apache MyFaces Tobago
  • Apache MyFaces Trinidad (needs the Trinidad support module)
  • PrimeFaces
  • JBoss RichFaces
  • ... (Every component lib which is spec. conform should work)
• Bean-Validation implementations
  • Apache BVal
  • JBoss Hibernate Validator v4+
• JPA
  • Apache OpenJPA
  • JBoss Hibernate
  • EclipseLink
  • eBeans
• Other libs
  • Apache MyFaces ExtVal
  • PrettyFaces
  • ... (any other lib which doesn't implement or extends a JEE spec.)

Please report further libs which work. Also notify us if you see any issue.

Servers

We have tested MyFaces CODI with:

• Tomcat 6.0.24+, 7.x
• Jetty 7.1.5+, 8.x
• JEE 6 Application-Servers
  • Apache TomEE (for Beta2 please read this hint)
  • JBoss Application Server v7
  • WebSphere v8.0.0.1+
  • 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.1.1+ since it's the most stable version we have tested.)
  • Glassfish 4b24 (2012-02-12)
  • WebLogic 12c with CODI v1.0.5+ (for versions <= 1.0.4 : needs some special steps - see External Resources)
• JEE 5 Application-Servers + OWB (e.g. Weblogic 10.3, WebSphere)
• CDI implementations
  • OpenWebBeans v1.0+
  • Weld v1.1.1+ recommended
• SpringSource dm Server
• Siwpas (read this hint)

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

Other portable CDI extensions

Basically MyFaces CODI is compatible with all other CDI extensions. The only exception: if both provide producer methods for the same artifacts. Therefore, MyFaces CODI allows to deactivate those classes or you can do it manually with a custom extension which does a veto on one of both producer methods.

Explicitly tested

• https://github.com/openknowledge/openknowledge-cdi-extensions

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.