This doesn't seem right. I was doing some cleanup of my code and I just noticed this. Every ajax request is firing the constructor and #PostConstruct of my #ViewScoped bean. Even a simple database pagination is firing it.
I understood that #ViewScoped is longer than #RequestScoped and that it shouldn't be reconstructed on every request. Only after a complete page reload by GET.
In other words, your #ViewScoped bean behaves like a #RequestScoped bean. It's been recreated from scratch on every postback request. There are many possible causes for this, most of which boils down that the associated JSF view is not available anymore in the JSF state which in turn is by default associated with the HTTP session.
Provided that you can assure that the HTTP session itself is not the root cause of the problem, i.e. when #SessionScoped works absolutely fine, then walk through the below list of possible causes. Otherwise, if the HTTP session itself is also trashed and recreated on every single request, then you need to take a step back and look at session cookie and server configuration. Any cause related to a broken HTTP session is at least beyond the context of JSF.
You're using Mojarra 2.1.17 or older, and the view contains EL expressions which bind a view scoped bean property to a tag attribute which is evaluated during view build time. Examples are JSTL <c:if>, <c:forEach>, etc or JSF <ui:include>, <x:someComponent id="#{...}", <x:someComponent binding="#{...}">, etc. This is caused by a bug in Mojarra (issue 1496). See also Why does #PostConstruct callback fire every time even though bean is #ViewScoped? JSF
This is already fixed in Mojarra version 2.1.18. If you can't upgrade to a newer version, the workaround is to disable partial state saving as below in web.xml, see also JSTL in JSF2 Facelets... makes sense?
<context-param>
<param-name>javax.faces.PARTIAL_STATE_SAVING</param-name>
<param-value>false</param-value>
</context-param>
Or when you want to target a specific set of JSF views only:
<context-param>
<param-name>javax.faces.FULL_STATE_SAVING_VIEW_IDS</param-name>
<param-value>/foo.xhtml;/bar.xhtml;/folder/baz.xhtml</param-value>
</context-param>
Important to mention is that binding the value of JSF component's id or binding attribute to a view scoped bean property is a bad practice. Those should really be bound to a request scoped bean property, or an alternative should be sought. See also How does the 'binding' attribute work in JSF? When and how should it be used?
You're using Mojarra 2.2.0, only that version has a (yet unknown) bug in maintaining the view scope which is already fixed in 2.2.1, see also issue 2916. Solution is to upgrade to a newer version.
The #ViewScoped annotation is imported from the wrong package. JSF offers two #ViewScoped annotations, one from javax.faces.bean package for JSF managed beans annotated with #ManagedBean, and another one from javax.faces.view package for CDI managed beans annotated with #Named. When the bean scope annotation does not match the bean management annotation, then the actual bean scope will become the bean management framework's default scope, which is #RequestScoped in JSF managed beans and #Dependent in CDI managed beans.
You need to ensure that you have either of the following constructs and don't mix them, see also #ViewScoped bean recreated on every postback request when using JSF 2.2.
import javax.faces.bean.ManagedBean;
import javax.faces.bean.ViewScoped;
#ManagedBean
#ViewScoped
public class CorrectJSFViewScopedBean implements Serializable {
import javax.inject.Named;
import javax.faces.view.ViewScoped;
#Named
#ViewScoped
public class CorrectCDIViewScopedBean implements Serializable {
The view is (accidentally?) marked transient via <f:view transient="true">. This basically turns on "stateless JSF", which is new since Mojarra 2.1.19. Hereby the JSF view simply won't be saved in the JSF state at all and logical consequence is that all referenced view scoped beans can't be associated with the JSF view anymore. See also What is the usefulness of statelessness in JSF?
The web application is configured with com.sun.faces.enableRestoreView11Compatibility context param set to true in an incorrect attempt to "avoid" ViewExpiredException. With this context param, the ViewExpiredException will never be thrown, but the view (and all associated view scoped beans) will just be recreated from scratch. However, if that happens on every request, then this approach actually hides another problem: the views expire way too soon. This indicates a possible problem in maintaining the JSF view states and/or the HTTP session. How to solve/configure that properly, head to javax.faces.application.ViewExpiredException: View could not be restored.
The web application's runtime classpath is polluted with multiple different versioned JSF API or impl related classes. This causes a corruption/mismatch in the identifiers/markers for the JSF view state. You need to make sure you don't have multiple JSF API JAR files in webapp's /WEB-INF/lib. In case you're using Maven, make carefully sure that you mark server-provided libraries as <scope>provided</scope>. See also "Installing JSF" section in our JSF wiki page and the answer to this related question: How to properly install and configure JSF libraries via Maven?.
When you're using PrimeFaces <p:dialog>, then make sure that the <p:dialog> has its own <h:form> and that it is not nested in another <h:form>. See also p:fileUpload inside p:dialog losing #ViewScoped values.
When you're combining PrimeFaces FileUploadFilter with PrettyFaces, then make sure that the FileUploadFilter also runs on PrettyFaces-rewritten/forwarded requests. See also ViewScoped bean rebuilt when FileUploadListener called using PrettyFaces and How to use PrimeFaces p:fileUpload? Listener method is never invoked or UploadedFile is null / throws an error / not usable.
When you're using PrettyFaces, a badly configured rewrite rule which redirects CSS/JS/image resources to a JSF page tied to a #ViewScoped bean will also give misleading behavior. See also CDI ViewScope & PrettyFaces: Multiple calls to #PostConstruct (JSF 2.2).
Related
The Question
Given that the archive we deploy is an "implicit bean archive" (see below), using #javax.inject.Inject to inject a #javax.annotation.ManagedBean into another managed bean work in WildFly 8.1.0, but it won't work in GlassFish 4.0.1-b08 nor GlassFish 4.1-b13. GlassFish crash with this message:
WELD-001408: Unsatisfied dependencies for type...
Do I misunderstand the following outlined specifications or do GlassFish have a bug?
CDI 1.1 Part 1
CDI 1.1 (JSR-346) section 12.1 "Bean Archives" says:
An explicit bean archive is an archive which contains a beans.xml file
[..]. An implicit bean archive is any other archive which contains one
or more bean classes with a bean defining annotation [..].
If then, my archive has no beans.xml descriptor file, I will still be able to use beans that have a "bean defining annotation". Question is, what is a bean defining annotation?
The CDI specification section 2.5 "Bean defining annotations" says:
Any scope type is a bean defining annotation.
So that's pritty clear and that's all there is to it according to this section of the CDI specification. If I deploy an archive with no beans.xml descriptor file in it, then I can #Inject beans as long as they have an explicitly declared scope, #javax.enterprise.context.RequestScoped for example. It works in both WildFly and GlassFish. However..
Managed Beans
The subset specification that all specifications within the Java EE technology stack must adhere to, Managed Beans (JSR-316), has a "base model" in which #javax.annotation.ManagedBean do define a managed bean. The managed beans specification doesn't say that #ManagedBean makes the bean a plausible injection target for an injection point (i.e., field or parameter). The specification do say that the beans "can be used anywhere in a Java EE application" (section MB.1.2 "Why Managed Beans?") which in my ears sound like they should be injectable too.
Java EE 7 Umbrella specification
The Java EE 7 specification (JSR-342) has this to say in section EE.5.24 "Support for Dependency Injection":
Containers must support injection points annotated with the
javax.inject.Inject annotation only to the extent dictated by CDI. Per
the CDI specification, dependency injection is supported on managed
beans.
There are currently three ways for a class to become a managed bean:
Being an EJB session bean component.
Being annotated with the ManagedBean annotation.
Satisfying the conditions described in the CDI specification.
Classes that satisfy at least one of these conditions will be eligible
for full dependency injection support as described in the CDI
specification.
There you go: #ManagedBean has "full dependency injection support". Not half or just a little bit of support. Yet, I'm not that sure exactly what "dependency injection support" is. But I think that the paragraph that follows describe it well enough:
Component classes listed in Table EE.5-1 that satisfy the third
condition above, but neither the first nor the second condition, can
also be used as CDI managed beans if they are annotated with a CDI
bean-defining annotation or contained in a bean archive for which CDI
is enabled. However, if they are used as CDI managed beans (e.g.,
injected into other managed classes), the instances that are managed
by CDI may not be the instances that are managed by the Java EE
container.
Basically, what this paragraph says is that the second condition is CDI managed beans that may be injected into other managed classes (because the exception beans "can also").
The umbrella specification and the managed beans specification has both made it somewhat clear that the CDI specification has the last word.
CDI 1.1 Part 2
The #ManagedBean annotation is only found mentioned in the CDI specification two times, both of which occur in chapter 11 which speaks of life cycle CDI events that a CDI extension can observe. Section 11.5.7 is one of the hits and define a ProcessInjectionPoint event. A managed bean may use dependency injection - no surprise there. However, section 11.5.8 define a ProcessInjectionTarget event. Here's what the specification has to say about the ProcessInjectionTarget event:
The container must fire an event for every Java EE component class
supporting injection that may be instantiated by the container at
runtime, including every managed bean declared using #ManagedBean, EJB
session or message-driven bean, bean, interceptor or decorator.
This phrase says undoubtedly that a #ManagedBean may be used as target for an injection point without adding the notion of scope types (#Dependent is always default).
As stated earlier, injecting a #ManagedBean from an implicit bean archive work in WildFly and as far as I can understand, this is required by all Java EE specifications just quoted. So I think it is GlassFish that has a bug. But the CDI spec never said a word about #ManagedBean in section 2.5 "Bean defining annotations", and as always, I'm a nervewreck when reading through overlapping Java EE specifications, so I thought I should ask before I go and file a "critical" bug to the GlassFish team.
EDIT 2014-08-22
Filed a GlassFish bug: https://java.net/jira/browse/GLASSFISH-21169.
This is not a complete answer as confusion will inevitably arise when we try to put together and make sense out of all specifications. I just wanted to say that CDI 1.2 has made a clarification about what exactly a bean defining annotation is (see section "2.5.1. Bean defining annotations"). CDI 1.2 give a list:
The set of bean defining annotations contains:
#ApplicationScoped, #SessionScoped, #ConversationScoped and #RequestScoped annotations,
all other normal scope types,
#Interceptor and #Decorator annotations,
all stereotype annotations (i.e. annotations annotated with #Stereotype),
and the #Dependent scope annotation.
It should be added that what defines a "normal scope type" (second bullet point) is a custom scope annotated #NormalScope.
I am starting a new project with JavaEE 7 and declared a Sessionscoped bean to maintain the web logged user information in session.
The UserSessionBean, as I named it, is intended to be lightweight - trying to avoid lots of data to be kept in the session by Weld. But in some cases I need to get all user information, so added a getUser() method which must query and retrieve a UserEntity from JPA. In order for the method to do its job, I need to #Inject other resources onto the UserSessionBean.
My question is: These dependant resources will be kept and serialised within the UserSessionBean by Weld until the context is destroyed?
The weld documentation says this:
An instance of a dependent bean is never shared between different
clients or different injection points. It is strictly a dependent
object of some other object. It is instantiated when the object it
belongs to is created, and destroyed when the object it belongs to is
destroyed.
That makes me think the all SessionBean tree is kept by weld during session life, but how can I keep a lightweight SessionBean and use injected CDI resources on it?
Since what you're injecting are also CDI beans, it is not the beans themselves that get serialised, but their lightweight proxies. Upon deserialisation, the proxies dynamically resolve the correct beans for whatever scope they are. See section 5.4 Client Proxies of the CDI1.0 spec. Hence, your bean is as lightweight as possible.
This is a followup question to some questions on stackoverflow.com:
JSTL c:forEach causes #ViewScoped bean to invoke #PostConstruct on every request
Why does #PostConstruct callback fire every time even though bean is #ViewScoped? JSF
However, we're using Mojarra 2.1.22 but our Seam 3 CDI #ViewScoped annotated beans always become reconstructed, that is the method annotated with #PostConstruct is executed and we get an new bean on every AJAX request.
All I keep hearing for a few months (it's February 2014 now) is that Mojarra 2.1.18+ has many of these bugs fixed and that the view-scoped bean should survive AJAX requests when the view is using this bean from a <c:forEach items="#{mySeam3CdiViewScopedBean.items}" ... >.
Here are a few bugs:
https://java.net/jira/browse/JAVASERVERFACES-1665
https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-928 (<- see the last comment by dwightd - I cannot confirm it!)
https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-787
https://java.net/jira/browse/JAVASERVERFACES-2688
The only difference to the examples I mentioned at the top is that we're using Seam 3.1 Faces CDI #ViewScoped (+ #Named) and not "native" JSF #ViewScoped (+ #ManagedBean).
Question:
Is Seam 3 Faces (3.1 Final) the reason why it isn't working?
(How can we find out? It's not easy to translate what we have to a test case... maybe someone knows?)
PS: I know this is more of a forum question, but I have hopes that the people here dealing with JSF 2 but not necessarily Seam 3 (Faces) could give their feedback.
A few remarks about your questions :
Using JSTL loop in JSF is not recommended since it's not managed in JSF lifecycle. Using facelets ui:repeat is the good practice
Seam 3 is deprecated, you should avoid using it as you won't have any support if the problem comes from here.
You have two solutions (by order of preference) :
Switch to JSF 2.2x (and CDI 1.1) which integrates native CDI compliant #ViewScoped. You can easily do this by using JBoss Wildlfy 8 or Oracle Glassfish 4 servers.
If you cannot switch JSF, forget Seam Faces and switch to Deltaspike (the descendant of Seam 3 and CODI). It provides a CDI scope for the JSF #ViewScoped
But in both case, try to get rid of JSTL in your JSF pages, it is a source of a lot of strange issues.
I want to create a JSF-2 Portlet with multiple SessionScoped Backing Beans. I'd also like them all to share some POJOs with a common SessionScoped Bean that will serve as an Object Pool.
I have two issues troubling me:
I'd like to have this bean Initialized before any of the Backing Beans. Note that no xhtml page will call an object directly to the Object Pool Bean, so at least one Backing Bean will be init before the ObjectPool. Is there some way to make sure it will be init first, except that calling in in PostConstruct of every other Backing Bean ?
I am confused on using ManagedProperties, because I need All the Backing beans to call the Object Pool's properties, while I also need the Backing Bean to call some Client / BackingBean functions. How can I do that without creating double references ?
For your first question you can use a f:prerenderView in your
login xhtml page. #SessionScoped beans are not created until you
reference them from the page or create them by yourself and store in
the context. If you link the f:prerenderView to some of your method
of the bean which acts like a pool it will be initialized for the
rest of the HttpSession. You can later inject it in your other
#SessionScoped beans using #ManagedProperty annotation.
About your second question, just remember you're not forced to go
through the view beans in order to obtain session properties. Haven't
you made the Object Pool itself a #ManagedBean? So access it
directly from your page!
Old code creates a #SessionScoped #ManagedBean (namely UserSession) at the first request in a ServletFilter and puts it in the HttpSession (if not already there).
Now what happens when some EL expression tries to access that ManagedBean the first time? I expected a second instance of UserSession (one created manually and one from JSF). So I instrumented the constructor, #PostConstruct and #PreDestroy with a few logging statements. Now it seems JSF never creates the UserSession - only the constructor is called.
Is this possible? Can JSF reuse that bean from HttpSession? Is it legit to put #SessionScoped beans in HttpSession?
Your observation is correct. Under JSF's covers, JSF itself also stores session scoped managed beans as an attribute of the HttpSession. So if it's already present, it will just be reused, regardless of the way how it has ended up in there.
Whether that's good or bad depends on the concrete functional requirement. Given your astonishment, I'd guess that it's bad and that you need to revise either the approach or the functional requirement. Perhaps you need a secondary (session scoped?) managed bean which injects the particular session attribute by #ManagedProperty.