search

QeelwaEtech / omnifaces

Automatically exported from code.google.com/p/omnifaces
0 stars 1 forks source link

OmniFaces 1.4.1 NullPointerException at RestorableViewHandler.restoreView #154

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Duplicate steps similar to those steps I provided in Issue 75 and Issue 88.

What steps will reproduce the problem?
1. Logout of web app, so app redirects user to login.xhtml
2. Shutdown app server (TomEE 1.6.0 SNAPSHOT 3/12/2013)
3. Replace OmniFaces 1.3 JAR with OmniFaces 1.4.1 JAR in web app, generate and 
deploy WAR to TomEE
4. Start TomEE
5. On login.xhtml page (browser remained opened since step #1 above), click 
Login (since user credentials are loaded via browser/Chrome's save-password 
feature)

What is the expected output?

No error/exception.

What do you see instead?

Exception is displayed in browser and stored in TomEE's localhost log file. See 
attached file.

What OmniFaces version are you using?
1.4.1 (downloaded within the last 1 or 2 hours)

What JSF impl/version are you using?
MyFaces 2.1.10, JSF 2.1

What servletcontainer impl/version are you using?
TomEE 1.6.0 SNAPSHOT 3/12/2013

If any, what JSF component library impl/version are you using?
PrimeFaces 3.5

Please provide any additional information below.

This issue does not occur with OmniFaces 1.3 JAR and all listed above.

Original issue reported on code.google.com by smithh03...@gmail.com on 17 Mar 2013 at 2:04

Attachments:

GoogleCodeExporter commented 9 years ago 
Have you used any 1.3 snapshot before? This change was one of the first changes 
for 1.3.

I will investigate it.

Original comment by balusc on 17 Mar 2013 at 3:58

GoogleCodeExporter commented 9 years ago 
FYI: can't reproduce in Tomcat 7.0.37.

The exception indicates that ViewDeclarationLanguage can't be found. Can you 
please let me know which URL pattern your FacesServlet is been mapped on? I 
used *.xhtml.

Original comment by balusc on 17 Mar 2013 at 4:17

GoogleCodeExporter commented 9 years ago 
Yes, I used OmniFaces 1.3 snapshot prior to using OmniFaces 1.3 release, but 
OmniFaces 1.4.1 is the first time that I used 1.4 version.

My apologies. Myself and endusers access login.xhtml via login.jsf, and after 
successful login, the app redirects to index.xhtml via userBean.loginUser() 
returning "index.jsf?faces-redirect=true".

Below, is part of the web.xml.

    <filter-mapping>
        <filter-name>LoginFilter</filter-name>
        <url-pattern>*.jsf</url-pattern>
    </filter-mapping>

    <servlet>
        <servlet-name>Faces Servlet</servlet-name>
        <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>

    <servlet-mapping>
        <servlet-name>Faces Servlet</servlet-name>
        <url-pattern>*.jsf</url-pattern>
    </servlet-mapping>

FYI, I really was not motivated to migrate to 1.4 (at all), because I didn't 
see anything that I really needed, even though someone else reported some issue 
related to PrimeFaces 3.5, but my PrimeFaces 3.5 app has no issues with 
OmniFaces 1.3 at all. I just decided to OmniFaces 1.4.1...just to see if 
OmniFaces 1.4 would cause any issues with my app.

Original comment by smithh03...@gmail.com on 17 Mar 2013 at 9:58

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
I couldn't reproduce the particular exception, but I could reproduce the 
problem as described in comment 6 of issue 75. It's fixed in the below 
snapshot, can you please let me know if it fixes your particular problem as 
well? 

Sorry for the regression. We really need a testing farm.

Original comment by balusc on 18 Mar 2013 at 4:12

Attachments:

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
It is not necessary to for me to migrate from OmniFaces 1.3 to 1.4.1 at all, 
but since I like to have the latest and greatest, and since I experienced this 
issue (and assumed that my endusers would experience the same issue), I decided 
to report this issue.

Agreed and I apologize for not providing a testing farm.

I repeated the steps that I provided in OP, and with that, I will mention one 
requirement/prerequisite, which is OmniFaces 1.3 had to been running and user 
logged into app prior to completing step #1.

omnifaces-1.5-SNAPSHOT-20130318.jar fixes this issue, but I wanted to report 
the 'unexpected behavior' that I experienced.

1. Completed steps 1 thru 5 (as listed in OP)
2. App did not complete the 'loginUser' method, no exception displayed in 
browser, no exception in localhost, so the login page displayed again, and the 
following was in tomee's stderr and/or catalina log (which shows that the 
server started, and then I attempted to login, but 'loginUser' was not 
executed):

INFO: Server startup in 10440 ms
Mar 18, 2013 3:28:13 AM org.apache.myfaces.el.unified.ResolverBuilderBase 
sortELResolvers
INFO: Chain of EL resolvers for Faces sorted with: 
org.apache.myfaces.el.unified.OpenWebBeansELResolverComparator@25fa3dbb and the 
result order is 
[org.apache.myfaces.el.unified.resolver.implicitobject.ImplicitObjectResolver@4f
ead377, 
org.apache.myfaces.el.unified.resolver.CompositeComponentELResolver@41e1529e, 
org.apache.myfaces.el.FlashELResolver@2ff724dc, 
org.apache.myfaces.el.unified.resolver.ManagedBeanResolver@a95001e, 
org.apache.myfaces.el.unified.resolver.ResourceResolver@3c3ab6ff, 
javax.el.ResourceBundleELResolver@32c43e3d, 
org.apache.myfaces.el.unified.resolver.ResourceBundleResolver@71d230d4, 
javax.el.MapELResolver@1e83e8ad, javax.el.ListELResolver@6620c581, 
javax.el.ArrayELResolver@7186cc88, javax.el.BeanELResolver@48de2ef2, 
org.apache.webbeans.el.WebBeansELResolver@72dc373d]

3. So, after 2 minutes, I decided to click Login button again, just to see what 
happens, and the app logged me in, without issue/exception (as expected). 
Below, is what was in tomee stderr/catalina log after completing this step #3.

Mar 18, 2013 3:30:32 AM jsf.users.pf_UsersController loginUser
INFO: pf_UsersController.loginUser(): administrator logged in at Mon Mar 18 
03:30:31 EDT 2013
Mar 18, 2013 3:31:48 AM jsf.users.pf_UsersController logout
INFO: pf_UsersController.logout(): administrator logged out at Mon Mar 18 
03:31:48 EDT 2013

Conclusion: OmniFaces 1.3 would have logged me in successfully after completing 
steps 1 thru 5 in OP, but OmniFaces 1.4.1 and 1.5 introduces 
abnormal/unexpected app behavior.

I wanted to try to repeat original test steps but clear tomee's work folder as 
step '3a', prior to starting TomEE. will let you know the test results. thanks.

Original comment by smithh03...@gmail.com on 18 Mar 2013 at 7:49

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
I had to delete comment #8 above, because I made a mistake in my 
build-deploy-WAR step. :)

I repeated test steps (without deleting/clearing tomee/temp or tomee/work 
folders), but test step #3 (in OP), I did the following instead:

3. Replace OmniFaces 1.5 SNAPSHOT JAR with OmniFaces 1.3 JAR in web app, 
generate and deploy WAR to TomEE

And still, with OmniFaces 1.3, I am not able to duplicate exception in OP and 
not able to duplicate the behavior noted in comment #7 above.

Next, will clear tomee/temp and tomee/work folders and retest with Omnifaces 
1.4.1 and 1.5 SNAPSHOT JARs.

Original comment by smithh03...@gmail.com on 18 Mar 2013 at 8:08

GoogleCodeExporter commented 9 years ago 
Deleted files/folders in tomee/temp and tomee/work (but not 
tomee/temp/safeToDelete.tmp, since that is included in tomee ZIP file), and 
repeated steps listed in OP, and duplicated the issue reported in OP.

Step #3 was left as-is:

3. Replace OmniFaces 1.3 JAR with OmniFaces 1.4.1 JAR in web app, generate and 
deploy WAR to TomEE

Original comment by smithh03...@gmail.com on 18 Mar 2013 at 8:17

GoogleCodeExporter commented 9 years ago 
BalusC, I would assume that OmniFaces 1.3 handles the situation, best.

Please note, I have a login servlet-filter in place (one of many that I saw you 
provided to people on stackoverflow.com), which will initiate http session and 
test if 'user' bean is valid/instantiated.

I am assuming that http session has been instantiated after completing step #1 
in OP, and OmniFaces 1.3 restores view more cleanly and 'successfully' better 
than OmniFaces 1.4.1 and 1.5 SNAPSHOT.

Since I don't have a test farm to provide, please feel free to mark this as 
Fixed. :)

Original comment by smithh03...@gmail.com on 18 Mar 2013 at 8:23

GoogleCodeExporter commented 9 years ago 
I assume that myself and my endusers will continue to see the behavior recorded 
in comment #7 above, since I have already deployed OmniFaces 1.5 SNAPSHOT to 
production server and will see how it performs. So far, I don't see any other 
defects/issues.

Recently, I have been in stable-version mode, and OmniFaces 1.3 is very stable 
with my app-and-environment. :)

Original comment by smithh03...@gmail.com on 18 Mar 2013 at 8:41

GoogleCodeExporter commented 9 years ago 
Assumption in Comment #12, because i stop/shutdown TomEE, when I need to 
build-n-deploy new WAR, and i usually always repeat steps in OP (logout, 
build-n-deploy new WAR, restart TomEE, and login).

I am sure that endusers will duplicate the logout-and-login (after I/Howard 
updates web app software on production server), and endusers will experience 
behavior noted in comment #7 above.

At most, they may say, i clicked Login, but I had to click Login button one 
more time and it logged me in. :)

Original comment by smithh03...@gmail.com on 18 Mar 2013 at 8:46

GoogleCodeExporter commented 9 years ago 
OmniFaces 1.5 SNAPSHOT has been running on production server, and I have 
heard/seen no issues in tomee logs and endusers have NOT reported any issues.

As requested earlier, please mark this issue as fix. I can be okay with 
behavior/regression reported in comment #7 above...if that continues to happen 
when i update web app software on production server.

Original comment by smithh03...@gmail.com on 18 Mar 2013 at 6:28

GoogleCodeExporter commented 9 years ago 
Thank you. 

Fix was already checked in 
https://code.google.com/p/omnifaces/source/detail?r=c21197b442b81657a23c5b28ae67
eb27c94b7267

Original comment by balusc on 18 Mar 2013 at 10:56

GoogleCodeExporter commented 9 years ago 
You're welcome. Is there an explanation about the difference in behavior or 
performance between OmniFaces 1.3 restore view and OmniFaces 1.4.1/1.5-snapshot 
restore view?

Original comment by smithh03...@gmail.com on 18 Mar 2013 at 11:21

GoogleCodeExporter commented 9 years ago 
Downloaded omnifaces-1.5-SNAPSHOT-20130430.jar and now I am 'not' able to 
duplicate the unwanted/unexpected behavior reported in comment #7 above. :)

Original comment by smithh03...@gmail.com on 11 May 2013 at 4:12