Your browser does not support iframes
This Confluence has been LDAP enabled, if you are an ASF Committer, please use your LDAP Credentials to login. Any problems file an INFRA jira ticket please.
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.
Neither CDI nor MyFaces CODI is bound to JEE 6, therefore you can choose the right time for using them in your Java 5+ applications.
The Apache MyFaces community provides the usual community support. Please contact the dev or users mailing list.
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.)
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:
Please report further libs which work. Also notify us if you see any issue.
We have tested MyFaces CODI with:
Please contact us if you face any issues with the server of your choice.
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.
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.