I've read out the difference between the two techniques and able to found only few differences which are not helping me to decide which to use with JSF. @ManagedBean is provided by JSF framework and CDI is supported for native Java6 itself, so which one could be a good combination irrespective of other frame work depedency?
Can anyone please inform me about this with nice examples? Thanks in advance.
No pain, No gain.
OCJP 1.6, Liferay Certified Developer 6.1
You can easily be led to believe that CDI is the future and that managed beans will be consigned to the
scrapheap, yet when you look into it I wouldn't say that there are loads of big advantages right now.
The main problem I initially encountered when looking to move to CDI was that CDI has no view scope,
and all my beans were view scoped. I then found out that Seam 3 provided a view scope, but that there
were some terminal compatibility problems with Seam 3 and Weld 1.1 as packaged with Glassfish 3.1.
What I would strongly suggest looking at is Myfaces CDI extensions (aka Myfaces CODI) which can be
found here: http://myfaces.apache.org/extensions/cdi/. This can be positioned similarly to Seam 3 in
that it provides some additional useful stuff, notably scopes. There's @ViewAccessScoped which has
alleviated all the frustrations I had with the limitations of the out of the box scopes provided with both
CDI, managed beans, and Seam 3, all in one go. It basically keeps a bean in scope until the first request
of a new view doesn't access it. This allows you to get rid of unwieldly view parameters, amongst other
CODI provides a better thought out conversation scope, and conversation scope groups. You can @Inject
ejbs into converters and validators instead of using jndi lookup also. You need to root about a bit on the
wiki to find the documentation, but whilst not extensive at least there is some:
One interesting point to note that without changing a single line of code, just adding the CODI jars to your
project will cause it to use CDI instead of managed beans because the existing annotations are intercepted.
It took a little while to figure out which jars to include, so if you can use maven you'll be making life easy
Note that you do not have to be using the myfaces JSF implementation to take advantage of this, it works
fine with mojarra.
CDI annotations can be read only by Java 6 compilers, and managed beans annotations were able to read by old java compilers. But both are supported by Java 6 compiler. Is the managed beans concept belongs to generic concept or EJB related? Since I've not worked with EJB I really don't know. (If it belongs to EJB concept, how it is used here since there is no bean container?) Thanks for your support gentleman.
Joined: May 12, 2009
>CDI annotations can be read only by Java 6 compilers, and managed beans annotations were able to read by old java compilers.
> But both are supported by Java 6 compiler.
I wasn't aware of that, it's useful to know. I think managed beans are a JSF concept, they will call the EJB layer
typically to provide persistence services (indirectly). Although you don't have to use EJB, it sort of simplifies transaction
management, although I'm still not 100% sold on the rationale for using EJB to be honest.
Thank you so much Healey. I'm expecting the exact answer from one of our community person. ( I just posted one more in general java about the custom annotation reading by java compiler. If somebody answers for that, then we come to know whether JSF stuff or not).
The JSF 2.2 specification says: The annotations in the package javax.faces.bean will be deprecated in a version of the JSF specification after 2.2. Therefore, developers are strongly recommended avoid using those annotations and instead use the ones from Java EE 6 (CDI). In all relevant books/articles from A.Gupta, D.Weil, A.Bien, A.Gipson etc. CDI beans are recommended. CDI beans are far more flexible as you can make use of type safe injection filtered by qualifiers, interceptors, scopes, events, decorators, stereotypes and producer methods.