This question already has answers here:
Backing beans (#ManagedBean) or CDI Beans (#Named)?
(5 answers)
Closed 6 years ago.
Okay, so I have a JSF backing bean that needs a reference to another (#NoneScoped) bean.
Should I #Inject it or use #ManagedProperty to obtain an instance reference from the container?
Why use one and not the other, in my mind the two approaches achieve the same thing.
#ManagedProperty and #NoneScoped comes from the JSF 2.0 spec whilst #Inject comes from the CDI spec.
If you are just working on a servlet application that doesn't make any use of any of the others JavaEE 6 features, then go for #ManagedProperty. That annotation has also an advantage against #Inject: you can use EL (expression language) with it (although there are workarounds to get that in CDI).
Both annotations/containers seem to achieve "the same thing" but in very different ways and they work with different containers. Beans managed by CDI will be available to JSF but not viceversa. If you are annotating your beans with JSF specific annotations then forget about using custom qualifiers, interceptors, producer methods, etc. I usually prefer the approach with CDI because, at the end, it is more sophisticated but the choice will depend on your actual needs.
Wrapping it up, as it seems that you are just using JSF features then stick to the #ManagedProperty (CDI can't understand #NoneScoped annotations, in CDI all beans are under the #Default scope if none specified). Switching to CDI in your project might mean to replace not just the #ManagedProperty for an #Inject one, but all your #RequestScoped (and so on) for the CDI-specific ones.
I would favour CDI over managed beans whenever possible. CDI is richer in deploy-time dependency checking and its proxy support prevents scope leak. This makes it easier to verify the correctness of your model. Producers can generally be used to provide glue code where necessary.
CDI spec
Blog post on CDI and EL
Related
Jakarta Faces 4.0 introduced a new #ClientWindowScoped annotation. However, searching the specification and implementations, I haven't found any example of its practical use in applications.
Maybe it's not only the case to annotate a bean with this annotation, but also to manipulate the jfwid request parameter through some provided API. If that's the case, can anyone provide a simple example of how it can be used or point to an article that does?
I tried to debug of beans creation and understood that it is random order. What is the order of bean creation in Weld? Is there a graph of beans?
It won't be "Random". Generally everything will be "lazy" instantiated, but when demand for a bean occurs, it will reach to the bottom of the bean dependency graph and recursively instantiate dependencies. If two nodes occur at the same depth, order of instantiation may be undefined, but most certainly won't be randomized.
JSF provides the #ResourceDependency annotation that can be used with instances of javax.faces.component.UIComponent or javax.faces.render.Renderer.
My question now is: when and where are these annotations processed? I'm particularly interested in how Oracle's JSF implementation handles these.
I'm particularly interested in how Oracle's JSF implementation handles these.
They are processed via com.sun.faces.application.annotation.ResourceDependencyHandler when the component/renderer is being instantiated. The annotation metadata is however parsed once and cached applicationwide in com.sun.faces.application.annotation.AnnotationManager. This is called by a.o. com.sun.faces.application.ApplicationImpl#createComponentApplyAnnotations() implementation which is called by a.o. Application#createComponent() interface.
I don't know If this is the right place to ask this question.
How do I make some non technical person to understand "Facelets as View technology"?
I try it.
If you use JSF as presentation layer you can use the advantages of input validation for forms, have a direct data binding to one or more ManagedBeans also known as PoJos with annotation #ManagedBean or #Model/#Named...
JSF components also support the usage of Ajax, so you can update tableviews asynchronous after adding new entries for example.
summarizing in my opinion it is easier to built a modern feeling site by using JSF, there are many different implementations e.g. primefaces, richfaces, etc. so you have the choice which framework you'll use.
Hope this helps, maybe the community can add more.
Patrick
JSR-299 (CDI) introduces the (unfortunately named) concept of a resource: http://docs.jboss.org/weld/reference/1.0.0/en-US/html/resources.html#d0e4373
You can think of a resource in this nomenclature as a bridge between the Java EE 6 brand of dependency injection (#EJB, #Resource, #PersistenceContext and the like) and CDI's brand of dependency injection.
The general gist seems to be that somewhere (and this will be the root of my question) you declare what amounts to a bridge class: it contains fields annotated both with Java EE's #EJB or #PersistenceContext or #Resource annotations and with CDI's #Produces annotations. The net effect is that Java EE 6 injects a persistence context, say, where it's called for, and CDI recognizes that injected PersistenceContext as a source for future injections down the line (handled by #Inject).
My question is: what is the community's consensus--or is there one--on:
what this bridge class should be named
where this bridge class should live
whether it's best to localize all this stuff into one class or make several of them
...?
Left to my own devices, I was thinking of declaring a single class called CDIResources and using that as the One True Place to link Java EE's DI with CDI's DI. Many examples do something similar, but I'm not clear on whether they're "just" examples or whether that's a good way to do it.
Thanks.
This seems highly subjective but I prefer to make several classes and I call FooProducer a class producing a Foo.