Your browser does not support iframes
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.
The Apache MyFaces community provides the usual community support. Please contact the dev or users mailing list.
http://www.irian.at/myfaces_codi/
Your browser does not support iframes
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.)
https://issues.apache.org/jira/browse/EXTCDI
We suggest to use MyFaces CODI in combination with Apache OpenWebBeans (OWB) - it's a powerful duo. 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!
We have tested MyFaces CODI with:
Please contact us if you face any issues with the server of your choice.
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 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.
Hint
Also APIs which are published before v1 GA might change e.g. based on the feedback of the community. However, we also have to change e.g. the documentation - so we will only do that if it really makes sense. So feel free to provide your feedback as soon as possible.
