Hi,
On Fri, Oct 9, 2015 at 10:52 PM, Leonardo Uribe <leonardo.uribe_at_irian.at> wrote:
> 1. Is the code still on JSF side?
Of course.
CDI has already clearly stated that they are not going to adopt the
"EJB approach". This means CDI is *not* going to contain code
(anymore) for/from other specs. In other words, CDI is not going to be
an umbrella that contains (abstractions) for JSF, JMS, JTA and what
have you.
Instead, it's the other way around. Already JTA, JSF and JMS sit on
top of CDI, and use CDI as a lower level library.
> 2. How are the objects created?
The objects are ultimately created via the native JSF API but via a
CDI "dynamic producer" (Bean<T>). To be exact it's this:
public class ViewProducer extends CdiProducer<UIViewRoot> {
private static final long serialVersionUID = 1L;
public ViewProducer() {
super.name("view")
.scope(RequestScoped.class)
.beanClassAndType(UIViewRoot.class)
.create(e -> FacesContext.getCurrentInstance().getViewRoot());
}
}
> I saw that you can use
> @Inject over javax.faces.component.UIViewRoot, but if that
> so, how will a session scope bean with an UIViewRoot be
> passivated without serialize/save the UIViewRoot?
The UIViewRoot is @RequestScoped, which means CDI will create a proxy
for this. When the session scoped bean is passivated, the proxy itself
is serialised, but not the bean it proxies. E.g in this case not the
UIViewRoot itself.
When the session scoped bean is activated again, the proxy is
deserialised and via a special ID it locates the dynamic producer
(Bean<T>) that originally was used for the proxy to be injected. If
the deserialised proxy is accessed the dynamic producer is used to
re-generate the value, which means calling into the native JSF API
again.
Effectively you could say that after a session scoped bean is
deserialised it simply re-injects the request scope bean, which will
then dynamically proxy to whatever the UIViewRoot is for the current
request.
Hope this makes it more clear.
Kind regards,
Arjan Tijms