JSF / EL occasional failure to resolve action method - jsf

Environment:
JSF 2.1.11
el-api 2.2
Eclipse Kepler
Tomcat 7
Chrome
IE-11
I have a working xhtml and bean which contains several action methods and work fine.
I added another commandButton:
<h:commandButton id="idBtnSave" value="Save"
action="#{imageMetadataEditProvider.saveLabelWithBox}"></h:commandButton>
...and the action method:
public void saveLabelWithBox() {
saveBoundingBox();
saveImage();
}
... then for some inexplicable reason, EL cannot find method saveLabelWithBox on the bean.
I did several rounds of renaming the method, rebuilding, undeploying and cleaning the Tomcat environment, redeploy. That almost always failed.
HOWEVER, What seemed to work was simply to move the saveLabelWithBox(){} block to elsewhere in the bean. Suddenly, it worked again, so I gullibly renamed the method to something more meaningful, then it failed again... EL could not find the method. So I again renamed it and moved it, rebuilt, redeployed, now it works again.
I'm curious whether others have had such quirky behavior and what you think might cause this, beyond the typical suspects of corrupt Eclipse workspace, or being on a microwave beam path.

I finally resolved this quirky problem which seemed related to corruption in the environment. The cure seemed to be to create a new bean with a different name and import all the methods from the formerly unreliable bean. I also did the usual Eclipse -clean startup, although that seemed to have no effect. I also removed the Eclipse .metadata and restarted, although that also seemed to have no effect.
Oddly, after building a new replacement bean, it would not load via annotations:
#ManagedBean
#ViewScoped
...so I was obliged to define the replacement bean in faces-config, and then it would load at page request time. I think there is still something screwed up in the environment. But all the methods are now being resolved and it's been working OK for a couple of days.
Your mileage may vary.

Related

JSF - Appropriate bean scope for keeping data between pages but only "browser tab related"

I am creating a web application using JSF 2.2.20 in which I am implementing a "kinda wizard" flow which lets the user filling input fields and go back and forth the view pages through navigation. I am using a single bean for all these views.
Let's say I have views A.xhtml, B.xhtml, C.xhtml and D.xhtml, all managed by the same bean MyBean.java
I want my application to be "browser tab scoped", which means that
I do not want my bean's data be re-instantiated after every HTTP Request as it happens with #RequestScoped beans or after view changing as it happens with #ViewScoped, I want the data of my bean to be kept between view changes and redirections so the user can go back and forth between pages without losing the data he has already given.
I do not want to use the #SessionScoped scope since each time the user opens a new tab I want the bean to be re-instantiated starting from page "A.xhtml.
Is there any built-in way to achieve the scenario described above using the current JSF version? In case there is not any, could you please propose any workarounds?
Thanks in advance!
I think #ViewScoped is what you are looking for, but it depends on your exact usage.
Couple of notes:
Use javax.faces.view.ViewScoped. Don't use the deprecated managed bean annotation as it works differently.
#ViewScoped works by storing the beans in the view. So each time you load the page you get a view and a viewId that corresponds to that view. So effectively each load of the page (could be read as 'each browser tab') gets its own bean.
#ViewScoped is a passivating scope. That means your beans, and their injected Dependencies, do need to be Serializable.
Use a recent, up-to-date version of your app server, or if you bring in MyFaces manually, use the latest release. I found a number of older versions implementations buggy 5+ years ago, but it seems to work flawlessly now.
If there is a Page Navigation occurring, you probably want to use FlowScoped. This is a multi-page bean that stays alive until you end the 'flow'.
If neither of these two work, you can always implement your own scope which is surprisingly easy with CDI.

#ConversationScoped bean behaves as #RequestScoped since OmniFaces 2.5 FacesViews

I tried to upgrade my Java EE 7 / JSF 2.2 application to Omnifaces 2.6. Currently I am running version 2.4.
After that, I have noticed a strange behavior when using #ConversationScoped and Ajax-Requests. When calling, the area, which should get rendered after the request, gets cleared (no exception on the server, response status code 200).
Next, I have a kind of wizard implementation, based on #ConversationScoped. It holds a class called ViewManager which has itself a List of Views. Initializing works fine and this list gets filled. But somehow it gets cleared (set to null) when the first form/view gets submitted. The setter for this is never called after the initialization, so it is not changed by my code. Somehow the view manager instance is still available, only this list of view within the view manager is null, which is kind of strange.
With omnifaces 2.4, everything did work fine (this is why I did not add some code of my wizard). I checked the changelog and noticed the MultiViews configuration when using ExtensionlessURLs. Don't know why this could effect my problem, but i tried it...with no success.
I have no idea what could be the problem, so maybe you can help me.
Thanks in advance :)
In OmniFaces, the FacesViews extensionless URLs feature got in version 2.5 an overhaul in order to support the so-called MultiViews as you can read on this blog.
During this overhaul I made a backwards compatibility mistake in the FacesViewsViewHandler where the <h:form> action URL is being manipulated in order to include the virtual folders of the MultiViews feature. The query string parameters were dropped from the original action URL and not added back.
The #ConversationScoped relies on the cid request parameter being present in the <h:form> action URL as in /context/page?cid=1. This thus became /context/page and therefore the conversation isn't retained across postbacks.
I will fix this in next OmniFaces release, for now you can get back the desired behavior by adding the below context parameter to web.xml.
<context-param>
<!-- Workaround for disappearing #ConversationScoped ?cid= parameter -->
<!-- This can be removed in next OmniFaces version after 2.6 -->
<param-name>org.omnifaces.FACES_VIEWS_VIEW_HANDLER_MODE</param-name>
<param-value>BUILD_WITH_PARENT_QUERY_PARAMETERS</param-value>
</context-param>
This parameter triggers a different way of building the URL whereby the entire query string from the original action URL is explicitly retained.

JSF: Mojarra vs. OmniFaces #ViewScoped: #PreDestroy called but bean can't be garbage collected

This question is specific to the OmniFaces #ViewScoped bean (however of interest to wider discussion about memory leakage and resource disposal with JSF #ViewScoped). It is based on the results of this NetBeans8.1 test web app available on GitHub:
Investigation of undesirable holding of references to various forms of JSF #ViewScoped beans by navigation type
https://github.com/webelcomau/JSFviewScopedNav
That test web app has a comprehensive README with complete instructions, as well as annotated test web pages comparing obsolete JSF2.0-style #ManagedBean #ViewScoped, JSF2.2-style CDI-friendly #Named #ViewScoped, and OmniFaces #Named #ViewScoped beans.
The results using JVisualVM for diagnosis are summarised in a downloadable spreadsheet (see also screenshot below), and indicate that while the OmniFaces-2.5.1 #ViewScoped bean invokes #PreDestroy methods under GET-based navigation cases when leaving a view (giving the opportunity to release most resources), it does not seem to permit garbage collection of the actual bean (at least not with the current context parameter settings).
In web.xml the application is set to use:
com.sun.faces.numberOfViewsInSession 4
com.sun.faces.numberOfLogicalViews 4
By default this OmniFaces-specific parameter is commented out:
org.omnifaces.VIEW_SCOPE_MANAGER_MAX_ACTIVE_VIEW_SCOPES
The javax.faces.STATE_SAVING_METHOD defaults to 'server'.
The main question is:
Q1: Is it correct that these OmniFaces #ViewScoped beans can't by design be garbage collected "live" (meaning through say provocation using a Profiler's garbage collectiong action, not waiting until a session is over) ?
Q2: If this is so, how can (should) one best force release of them on navigating away from pages (especially under GET navigations) ?
Q3: If not so (if my results are incorrect because of some other setting) why aren't I witnessing provoked garbage collection of them, and what can I do to ensure they are indeed automatically released ?
Since the test web app is downloadable, well documented and hopefully self-explanatory, I won't give code here, but simply the comparitive results so far, as well as screenshots of the test web app pages in action:
The cause of this problem seems to be due to strange behaviour JVisualVM when attached to Glassfish/Payara.
The test case used for this question is still extremely useful, however the conclusions concerning Garbage Collection in the original post (and images) were based on JVisualVM, and I have since found they are not valid.
Use the NetBeans Profiler instead !
I am now getting completely consistent results for OmniFaces ViewScoped with the test app on forcing GC from within the NetBeans Profiler (with 1 omnifaces view scoped bean left per open tab).
When using JVisualVM attached to GlassFish/Payara I am getting references still held (even after #PreDestroy called) by field sessionListeners of type com.sun.web.server.WebContainerListener within ContainerBase$ContainerBackgroundProcessor, and they won't GC.
The image shows a screenshot of JVisualVM attached to Payara with only 1 tab open but still 9 OmniViewBean instances held, no matter how often GC is forced.
Updated results table using Mojarra-2.3.0 vs OmniFaces-2.6.6 in NetBeans IDE 8.2 Profiler
Updated test app sequence:

Using binding attribute causes javax.faces.FacesException: Cannot find component with identifier

I have a problem I can't quite get a handle on.
First the context: I am developing a web application using Primefaces 3.5 (yes, unfortunately I am stuck with this old version for now), running on JBoss 7.
There is a form with id "form" encompassing all following xhtml code.
I have a component in my view which is provided by usage of the binding attribute:
<p:dashboard id="dashboard" binding="#{myBackingBean.dashboard}" />
Then sometimes I would like to perform an ajax update on this component, this is done by using the RemoteCommand component of primefaces:
<p:remoteCommand
actionListener="#{myBackingBean.someActionListener()}"
process="#this" id="myRmtCmd" oncomplete="myJsFunction();"
update=":form:dashboard" name="myRemoteCommand" />
The RemoteCommand is triggered by a clicking on a Link:
Some Text
This works pretty well so far. However after deploying this code to production I sometimes get a FacesException:
javax.faces.FacesException: Cannot find component with identifier ":form:dashboard"
referenced from "form:myRmtCmd".
This is where my problem lies because I cannot reliably reproduce this exception. My question is this: What could lead to this exception being thrown? It seems to work 95 % of the time but being the perfectionist I am (and many of you reading this are as well, I'm sure ;) ) I would like this code to work 100 % of the time. What am I missing?
Before answering please consider these constraints:
yes, i have to use the binding attribute for providing the dashboard as I need a great deal of control over what gets added to the component
to avoid using IDs I also tried updating the dashboard by its css class via one of primefaces' advanced selectors: #(.ui-dashboard) - this also does not work!
yes, it would be possible to use a commandbutton/link instead of wiring up the remotecommand component to a simple html link but in this case the link is rendered by a JSF renderer component and I made some bad experiences with dynamically adding buttons etc (due to JSF Spec Issue 790)
Cheers,
p.s.
I also had this weird behavior.
There are probably more than one component bindded to #{myBackingBean.dashboard}, so the first one sets the id and there will be no one called "dashboard".

Deleting a managed bean causes some weird situation in JSF

I had a managed bean called controlBean and i deleted it. Then i tried to add a new bean with the same name. I also had deleted it from faces-config.xml file, which was looking like this:
<managed-bean>
<managed-bean-name>controlBean</managed-bean-name>
<managed-bean-class>com.app.managedbeans.ControlBean</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
</managed-bean>
The problem is, even though i specify its name as controlBean again, NetBeans calls it controlBean1, and if i delete and add again it is called controlBean2 etc. Does anyone know the reason? What can i see to fix it?
Thanks
Please check you have added a default constructors for other managed beans.
I had the same issue with Netbeans 7.3. I have used annotations instead in that case. I added some methods to the few other beans. Stopped the GlassFish server. Deleted the dis and build folders manually. Clean and build the project again. Ant that error was not there for the time being. Don't know the exact cause. I had to do this few times for other beans as well.
If still not response, create a new bean and let it be there until a proper solution is available.
Get rid of all this XML and use the #ManagedBean annotation.

Resources