3

First of all, I am using OmniFaces CDI @ViewScoped which was recently added to and released in OmniFaces 1.6. I am very pleased to use OmniFaces CDI @ViewScoped in my app, but I have a question.

I noticed some NullPointerException's in my (TomEE 1.6 snapshot) server log, and I even experienced the NullPointerException's while testing pages that use/reference beans marked with OmniFaces CDI @ViewScoped. The NullPointerException's occur when I typically do something similar to the following:

(1) 'Render' a page that references/uses CDI @ViewScoped bean.

(2) Click a (PrimeFaces) commandButton/Link (below) which exists the 'view', and the commandButton/Link action="..." is responsible for destroying the @ViewScoped bean.

<p:commandButton value="Exit Messenger"
                 action="#{messengerBean.exitMessenger()}"
                 ajax="false"/>

and

public String exitMessenger() {
    pageNavigationController.setToBlankPage();
    // to destroy this CDI @ViewScoped bean
    return "index.xhtml";
}

(3) Immediately after step #2 above, myself or enduser does a 'browser refresh' (F5 key in Google Chrome), and for some/whatever reason, the CDI @ViewScoped bean (referenced by step #1 above) is reconstructed without the bean being reconstructed...correctly, since an actionListener=#{viewScopedBean.methodToPrepareStep1View()} or action="#{viewScopedBean.methodToPrepareStep1View()}" is 'not' invoked by the 'browser refresh' button/request.

(4) So, the @ViewScoped bean members are 'null' and NullPointerException's are being raised when users 'unexpectedly' press F5 or do a 'browser refresh'.

NOTE: state saving = server and (HTTP) Filter is instructing browser 'not' to cache the jsf/xhtml page via the following (which I learned from BalusC, long time ago, here on stackoverflow.com):

res.setHeader("Cache-Control", "no-cache, no-store, must-revalidate"); // HTTP 1.1.
res.setHeader("Pragma", "no-cache"); // HTTP 1.0.
res.setDateHeader("Expires", 0); // Proxies.

Also, I read the following other/related posts:

Is JSF 2.0 View Scope back-button safe?

What scope to use in JSF 2.0 for Wizard pattern?

ViewScoped works like RequestScoped - why?

jsf clearing the form

Is this due to bad design on my part (as 2-year-old JSF developer)?

Do I need to test all of my xhtml pages which reference CDI @ViewScoped beans, and repeat the steps that I listed above, and then just handle NullPointerException everywhere in my code...that is caused by 'browser refresh'? Is this the only way to resolve this or is there a better more-recommended way of handling (or avoiding) NullPointerException's caused by browser refresh after CDI @ViewScoped bean destroyed?

Please advise/confirm. Thanks.

EDIT: (2) above with 'correct' description and code that helps to replicate this issue.

Community
  • 1
  • 1
Howard
  • 792
  • 8
  • 43
  • The `` on a view scoped bean requires some trickery as it's also invoked during view build time and a change during postback requires a full rebuild of the view. First of all, are you able to exclude the OmniFaces CDI `@ViewScoped` from being the cause by recreating the same problem with standard JSF `@ViewScoped`? – BalusC Sep 25 '13 at 01:11
  • I probably can. I used ViewScoped many months/moons ago after reading some of your answers/posts here on stackoverflow (when I first started developing JSF), and then this response of yours 'just reminded' me that I had issues with JSF ViewScoped because of my usage of ui:include src="#{viewScopedBean.prepareView...()}", and I reverted to JSF SessionScoped, and then to CDI SessionScoped. When OmniFaces added CDI ViewScoped, i wanted to revert back to ViewScoped, (lol), but now I'm having this issue. I tried PRG, but then that felt to JSF 1.2'ish, so I got rid of that from the app. :) – Howard Sep 25 '13 at 02:09
  • You mentioned 'trickery' for this (type of) situation/scenario/issue. Sounds like something good to add to OmniFaces...to handle this...to make JSF developer's life...much much much easier! big :) – Howard Sep 25 '13 at 02:11
  • I considered it, but I gave up. See also http://stackoverflow.com/questions/13680192/dynamic-ajax-navigation-with-uiinclude/ In the meanwhile I've however learnt some new lessons, I might want to revisit this approach. – BalusC Sep 25 '13 at 02:38
  • Interesting. taking a look at it now. FYI, I am using OmniFaces enableRestorableView component and the commandButton/Link/menuitem's are ajax="false". does your recommended solution/workaround apply to ajax="false", too? – Howard Sep 25 '13 at 02:53
  • something (another question) came to mind... if I replace some ViewScoped bean references with RequestScoped bean references, e.g. ui:include src=#{requestScopedBean.methodWhichWillInvokeViewScopedBean()}, is this also a possible solution/workaround? – Howard Sep 25 '13 at 02:57
  • @BalusC I know it does not 'answer' this question, but i have already resolved the 2 or 3 different exceptions caused by repeating the steps, mentioned earlier, to replicate this issue. Basically, I modified PostConstruct to make sure variables are initialized, I added 'beanMember != null' to PreDestroy, and I replaced ui:include src="#{viewScopedBean.page}" with src=#{requestScopedBean.page}, and requestScopedBean.page (getter method) referenced viewScopedBean.page. ViewScoped PostConstruct and PreDestroy are executed on browser refresh, and I don't have exceptions anymore, 'now'. :) – Howard Sep 25 '13 at 04:29
  • @BalusC if you have an answer for this behavior, I will definitely mark your answer as checked. I had to revert to 'trickery' (as you mentioned earlier). I do that a lot while developing JSF, but of course, I don't do trickery as good as you do, BalusC. :) – Howard Sep 25 '13 at 04:31
  • Please see EDIT (2) above...to successfully duplicate the issues, which prompted me to ask this question. – Howard Sep 25 '13 at 04:43

0 Answers0