Link Details

LOL

i was expecting Java code and they are showing XML, pathetic !

in which century are these people living

hi sorry, don't get you? JSF 2.0 comes with many annotations support to get rid of the XML configuration already.

voted down because of using ManagedBean instead of CDI beans. Please look at the examples in the Core JavaServer Faces book.

CDI is well supported in Application server, extra works are needed to make it support in servlet container like Tomcat. Unless you are really sure you need CDI and application server, else i'm more prefer with the classic managed bean.

Often time, your project doesn't need an application server...

How many CDI implementations are there at the time you blogged? Only Weld (OpenWebBean is still in its alpha/beta/milestone phase on Sep 9). This link (http://docs.jboss.org/weld/reference/1.0.0/en-US/html/environments.html#d0e4998) says that Weld can be used in Tomcat/Jetty. I don't have much free time right now, otherwise I'll post links saying why CDI beans should be preferred than ManagedBean.

Hi dxxvi, i know CDI come with a lot benefits, but you need to "install" something in Tomcat in order to make it work, it make your project tightly coupled and not portable enough, which is not preferable. Often times, the "server" task is not handle by you or developer, it's system administrator or client support. You are extremely hard to convince them to let you install "Weld", they will question about the server's stability and security. And mostly, they will reject your request and just use the core Apache + Tomcat.

When come to deployment, it's always not in your control. Just my concern, i understand the CDI benefits, and i will definitely follow it, if i can control the deployment :)

WTH is CDI

CDI is short for completely dull interface.

From the link I provided above: "To bind the BeanManager into JNDI, you should populate META-INF/context.xml in the web root with the following contents ... and make it available to your deployment by adding this to the bottom of web.xml". That means you don't need to "install" anything in Tomcat. You install everything in your application.
The only case you need to "install" Weld in Tomcat is when you need Servlet injection. Also from that link: "Weld also supports Servlet injection in Tomcat. To enable this, place the weld-tomcat-support.jar in $TOMCAT_HOME/lib ..."

This is a better JSF 2.0 introduction: http://www.dzone.com/links/r/jsf_basics.html. The application is built with maven, i.e. the application server / servlet container is not touched.

mkyong, CDI is perfectly portable. Every Java EE 6 implementation supports it. It's even included in the web profile, so there's absolutely no reason not to use it.

You might just as well say your code doesn't use the Servlet API, since otherwise you need an application server and your project doesn't always need that. It doesn't make sense, does it? Or maybe you say that your code can't use java.util.Map, since otherwise you need a JVM and your project doesn't always need that. This entire line of reasoning just doesn't make any sense.

Every Java EE (6) implementation supports Servlet, and likewise it also supports CDI (see e.g. http://blog.caucho.com/?p=384).

hi henk and dxxvi,

This is just my years of experience, after developed countless large and small projects for different kind of clients. Most are still deploy in Tomcat, using JDK, coupled with Struts, or Spring or Hibernate... not we do not want to change it, it's just client doesn't want to upgrade (after all, Tomcat administrator is more easy to hire), it's not easy to convince client to install an application server :). Often times, if you are working in a vendor company, you just have to follow the client's policy.

Java EE 6... how many projects are using it? Do you have confident to upgrade from a stable application to a new Java EE 6 spec? yes, may be you are, but again, your client will not allow you to do so, this is fact, client will never agree to do anything to break the system stability.

I know CDI is good, application server is awesome, Java EE is promising, in technical view, we are encourage to follow it. But, in working environment, especially, in more higher level like architect or technical lead, you have to consider in different areas like resources, support, portable, server,security... not because a new technology is invented, then all have to follow, you have to really make sure your project is required it.

No offense, just my thoughts on this topic. Once again, if your project need it, just implement it :)