h1. Table of Contents
{toc:style=disc|indent=20px|printable=false}
h1. Motivation
The Apache MyFaces Extensions CDI project (aka CODI) hosts portable extensions for Contexts and Dependency Injection ([JSR 299|http://jcp.org/en/jsr/detail?id=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.
{note:title=Hint}
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.
{note}
h1. Community (Support)
The Apache MyFaces community provides the usual community support. Please contact the dev or users [mailing list|http://myfaces.apache.org/extensions/cdi/mail-lists.html].
h1. External Professional Support
[http://www.irian.at/myfaces_codi/]
{iframe:src=http://people.apache.org/~gpetracek/myfaces/banner/irian.html|width=350|height=100|frameborder=0}Your browser does not support iframes{iframe}
h1. 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.)
h1. Issue tracker
[https://issues.apache.org/jira/browse/EXTCDI]
h1. Compatibility
h3. 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!+
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)
- Other libs
-- Apache MyFaces ExtVal
-- PrettyFaces
Please report further libs which work. Also notify us if you see any issue.
h3. Servers
We have tested MyFaces CODI with:
- Tomcat 6.0.24+, 7.x
- TomEE v6+
- Jetty 7.1.5+, 8.x
- JEE 6 Application-Servers
-- 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.)
- JEE 5 Application-Servers + OWB (e.g. Weblogic 10.3, WebSphere)
- CDI implementations
-- OpenWebBeans v1.0+
-- [Weld|EXTCDI:Problems with Weld|Provides important hints for Weld users] v1.1.1+ recommended
- SpringSource dm Server
Please contact us if you face any issues with the server of your choice.
h3. 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]
h1. Structure of CODI modules
Detailed information about CODI modules are available at [CODI Modules - Overview and Setup|EXTCDI:Module Overview|General information about the available CODI modules]
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. |