I have the following line in a JSF page:
<h:commandLink action="#{myBean.test}" value="Wizard Step"></h:commandLink>
I expect that when the page is loaded, the Bean corresponding to myBean will be instantiated (and I'll be able to see this in the eclipse debugger).
The rest of the JSF is working correctly, but this bean is not resolving (without any error).
How do I get the errors from the el failing to resolve the bean?
If there are EL errors, you will surely get an exception of javax.el package:
ELException: Represents any of the exception conditions that can arise during expression evaluation.
MethodNotFoundException: Thrown when a method could not be found while evaluating a MethodExpression.
PropertyNotFoundException: Thrown when a property could not be found while evaluating a ValueExpression or MethodExpression.
PropertyNotWritableException: Thrown when a property could not be written to while setting the value on a ValueExpression.
In your case, the managed bean is not constructed on initial request. This can only mean that the managed bean is not referenced elsewhere in the view. The EL in action attribute is only evaluated when the form is submitted. So the bean will only be constructed when the action is invoked. As a test, just put #{myBean} somewhere in the view. You'll see that it get constructed on initial request.
Your real problem is that command button action is simply not invoked, so the EL in its action attribute is simply not evaluated at all. The problem cannot be debugged nor nailed down in the EL side. There are a lot of possible causes for the button action not being invoked. You can find them all here: commandButton/commandLink/ajax action/listener method not invoked or input value not updated. The most common cause among starters is that the button is inside an repeating component like <h:dataTable> whose value is not properly preserved and returns a completely different value during the form submit request, or that the component or one of its components has a rendered attribute which is not properly preserved and defaults to false.
Related
I was reading some code and I found the next EL expression inside a JSF file:
${text['somefield']}
How is it work?.
Since I don't have access to the whole code, I can check what it is. Is it "text" a managed bean?.
Because I could understand the next code:
${someBean.text['somefield']}
(accessing a field array inside a bean but it's not the case.
text can be a managed bean, a CDI dependency (these are the 2 most likely)
text['somefield'] is reading somefield field of text object. text is likely to be a map, but it could be a normal bean too. It's equivalent to text.somefield
In the documentation, you can also find similar exampes:
${customer.address["street"]}
Which is similar to:
${customer.address.street}
I am running Mojarra 2.2.0.
<context-param>
<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
<param-value>client</param-value>
</context-param>
The managed bean action method is-
public void action() {
HttpSession session = (HttpSession) FacesContext.getCurrentInstance()
.getExternalContext().getSession(false);
System.out.println(session.getId()); // not null for stateful views
}
For stateless views session.getId() throws NPE
For views which are not stateless-
Firing a GET request, there is JSESSIONID=340041C96D5AA446D761C3602F54A76D
I read it here that-
For client side state saving mechanism, JSF won't create the session
and will store the view state in a hidden input field with the name
javax.faces.ViewState in the form whenever necessary.
Further, it's mentioned here that
JSF will indeed autocreate the session because the JSF view state has
to be stored over there. If you set the JSF state saving method to
client instead of server, then it won't be stored in session and hence
no session needs to be created
I think the above line is a source for trouble for me.
If you set the JSF state saving method to client instead of server,
then it won't be stored in session // FULLY AGREED
and
hence no session needs to be created. // This confuses because for
client side saving mechanism, a session id gets generated by the
servlet container & hence there is a session associated with the
request.
In reference to the discussion which I had with BalusC in this question,
I created a HttpSessionListener-
#WebListener
public class MyHttpSessionListener implements HttpSessionListener {
public void sessionCreated(HttpSessionEvent event) {
Thread.dumpStack();
}
public void sessionDestroyed(HttpSessionEvent event) {
}
}
See below attached screenshots(these 2 screenshots are for version 2.0.3, there must have been an old bug due to which the session was getting created)-
Libraby (Mojarra 2.2.0)-
When does JSF creates a session
Eaiest way to naildown this is creating a HttpSessionListener, putting a debug breakpoint on sessionCreated() method and inspecting the call stack who needed to get the session for the first time (and thus implicitly needs to create it).
In below example you will see a chain of getSession() calls in the call stack. You will see that FaceletViewHandlingStrategy.renderView() method is the one calling it for the first time.
After you click on FaceletViewHandlingStrategy.renderView() line in debugger's call stack, you will get into its source code (Maven will load source code automatically, otherwise you need to manually attach it).
You see, when server side state saving is enabled and the view to render is not transient (stateless), then JSF will implicitly create the session, just to ensure it's created on time in order to save the view (if the session was created later, e.g. during render response phase, you would otherwise risk exceptions like this Adding <h:form> causes java.lang.IllegalStateException: Cannot create a session after the response has been committed).
You'll in the source code also immediately see that when the state saving method is set to client, or when the view is stateless as in <f:view transient="true">, then JSF won't anymore implicitly create the session. Older JSF versions may do that as you figured, but this is to be accounted as a bug and ought to be fixed in a newer version.
If you would like to ensure statelessness and avoid accidental/unforeseen session creation, then you could just throw new IllegalStateException() inside sessionCreated() method. When that happens, you just have to look in call stack who's responsible for creating the session and then fix/change the code to not do that anymore.
what does it puts in a session map?
Under the covers, ExternalContext#getSessionMap() delegates to HttpSession#setAttribute()/getAttribute()/removeAttribute(). You can listen on those methods using a HttpSessionAttributeListener.
In below example you will see that ViewScopeContextManager.getContextMap() line calls SessionMap#put() method in order to put something in the session map. When you unfold the event argument, you will see the session attribute name and value, which is com.sun.faces.application.view.activeViewContexts and an empty ConcurrentHashMap respectively.
Indeed, I was using a #Named #ViewScoped which was referenced by an value expression on the particular page (you see EL resolver and Weld resolver further down in call stack). When you click ViewScopeContextManager.getContextMap() line in call stack, you'll see that it was just preparing a map in session scope in order to store view scoped beans.
That's just one example. There are more things which could be stored in the session. Using a debugger this way and inspecting the associated source code will tell a lot about the Why.
I use a managed bean to generate an HtmlPanelGrid, and then bind it in the xhtml file, like so
<h:panelGrid id ="questions" binding="#{ui.generatedComponents}" />
On this page is a form, with a dropdown, and whenever a value is selected, it shows the page. However, whe something is selected, every other (static i.e in xhtml page) component is shown, but the binded component is never shown.
However, if I re-request the page in the browser, it does show them.
Mucho confusing. Any ideas?
When using binding, you need to make absolutely sure that the property behind this attribute is exclusively been used by this component in the current view. The managed bean should not be in the session scope, because it would then share the same property between multiple views (browser windows/tabs) in the same session. It should of course also not be in the application scope. The managed bean should be at highest in request or view scope. The view scope makes the most sense for this particular purpose.
The getter method of the property behind binding should also contain no business code. It should solely return the property, nothing more. Any initialization needs to be done in the (post)constructor or an (action)listener method of the backing bean class. Any manipulation of this component property needs to be done in an (action)listener method of the backing bean class.
Not doing so may result in awkward behaviour.
How does exactly the following code work:
#{aaa.id}
<h:inputText id="txt1" binding="#{aaa}"/>
I mean, usually the component binding works, by specifying a property (of type UIComponent) in a bean. Here, there's no bean nor property but nevertheless the name "aaa" gets bound correctly (displaying the component id - "txt1"). How does it work/where is it specified?
Thanks
UPDATE: The JSF2.0 Spec [pdf] (Chapter 3.1.5) says:
"A component binding is a special value expression that can be used to facilitate “wiring up” a component instance to a
corresponding property of a JavaBean... The specified ValueExpression must point to a read-write JavaBeans property of type UIComponent (or
appropriate subclass)."
It's been put in the default EL scope during building of the view tree (that's when all binding attributes -- and attributes of tag handlers like JSTL <c:xxx> and JSF <f:xxx> -- are being evaluated). It's being shown by normal EL means during rendering of the view tree. Rendering of the view tree happens after building of the view tree, so it works that way. It's not that this code runs "line by line" as you seemed to expect from the source.
I can't point you out a single reference where it's been specified as there is none. You'd have to read both the EL spec and JSF spec separately and do a 1+1=2.
By the way, to avoid confusion among new developers and to avoid clashes with existing variables in the EL scopes, you can use a java.util.HashMap in the request scope which is been declared as follows in faces-config.xml:
<managed-bean>
<description>Holder of all component bindings.</description>
<managed-bean-name>components</managed-bean-name>
<managed-bean-class>java.util.HashMap</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
</managed-bean>
and is been used as follows
#{components.aaa.id}
<h:inputText id="txt1" binding="#{components.aaa}"/>
which is more self-documenting.
See also:
How does the 'binding' attribute work in JSF? When and how should it be used?
After adding a s:checkbox to my form, I get OGNL errors in the ParamsInterceptor:
WARN [OgnlValueStack] Error setting expression '__checkbox_filter.findRejected' with value '[Ljava.lang.String;#dc926f'
ognl.OgnlException: target is null for setProperty(null, "findRejected", [Ljava.lang.String;#dc926f)
I am aware that the extra hidden field with underscores in its name (__checkbox_filter.findRejected) was correctly added by Struts2.
I don't understand, however, why the ParametersInterceptor is trying to set this property, that was added by Struts2, on my Action (which obviously doesn't contain a '__checkbox_filter' property).
It is normal to see this OGNL error coming from with Struts2 checkboxes? How can I avoid it?
I've just stumble across the very same problem.
You need to place the Checkbox Interceptor BEFORE the Parameters Interceptor in your interceptor stack.
This is the case by default, so I guess that you're using a custom stack...
Most of the time the mistake in such cases is that we forget to write getters and setters for the attributes. So check whether the getters and setters are at their place.