Red Hat Bugzilla – Bug 1080249
RichFaces is not defined after adding a RF portlet to a page
Last modified: 2015-08-03 03:52:38 EDT
Description of problem: Platform BZ for https://issues.jboss.org/browse/GTNPORTAL-2581 How reproducible: Not always. A debugger helps to reproduce the issue constantly. Steps to Reproduce: 1. Build and deploy jsf2-rf4-hello-world-portlet quickstart. 2. Import jsf2-rf4-hello-world-portlet via Application Registry 3. Add an empty page ([Site Editor]->[Add New Page]) 4. Edit the page ([Site Editor]->[Edit Page]) 5. Drag&Drop jsf2-rf4-hello-world-portlet 6. Attach a debugger and set a breakpoint at PortalRequestHandler.java line.237. ==== 234 } finally { 235 236 // We close the writer here once and for all 237 Safe.close(context.getWriter()); 238 239 // 240 try { 241 for (ApplicationLifecycle lifecycle : lifecycles) 242 lifecycle.onEndRequest(app, context); 243 } catch (Exception exception) { ==== 7. Click save icon in portal 8. Debugger stops at PortalRequestHandler line.237. 9. Disable the breakpoint and 'step over' the execution in debugger 10. Then 'resume' the debugger Actual results: The browser displays a pop-up "RichFaces is not defined". See attached "RichFaces_is_not_defined.png" Expected results: The page is properly rendered with the portlet
Created attachment 878296 [details] RichFaces_is_not_defined.png
The issue is similar to BZ1059036. I wonder which is the problem --- "the architecture which responds before commit" or "ajaxRequest=true".
Testing with 6.2.0.DR2, I see the phenomenon is different. Actual results: The browser doesn't display a pop-up "RichFaces is not defined". But the portlet appearance is broken. See attached "620DR2_after_edit.png". Then I move to home page by clicking navigation, a pop-up is raised with a message "This portlet does not exist anymore, please refresh your browser". See attached "620DR2_after_edit_and_goto_home.png".
Created attachment 882208 [details] 620DR2_after_edit.png
Created attachment 882209 [details] 620DR2_after_edit_and_goto_home.png
Note: I set a breakpoint at PortalRequestHandler line.255 for 6.2.0.DR2. Other steps are the same.
Unfortunately, I'm still unable to reproduce this issue. I've tried with 6.1.1, master and 6.2.0.DR2, without success. I've requested assistance from QA, so that they can also try to reproduce this issue. It would also be interesting to see if you can reproduce this issue on Fedora 20 with all updates.
Hi, I was not able to reproduce it as well. After resuming the debugger everything works as expected. None of the described issues happened in my environment.
Reproduced the issue in RHJP 6.1.1 by my colleague. So far the environments we have reproduced are: Fedora 17 / Oracle JDK 1.7.0_45 / Firefox 21 Fedora 17 / Oracle JDK 1.7.0_45 / Chrome 24 Fedora 20 / Oracle JDK 1.6.0_45 / Firefox 28 Fedora 20 / OpenJDK 1.7.0_51 / Firefox 28 I think the problem is not environment but steps: ===== 8. Debugger stops at PortalRequestHandler line.237. (Safe.close(context.getWriter());) -> This means stopping before responding to browser 9. Disable the breakpoint and 'step over' the execution in debugger -> By 'step over', the thread proceeds *1 line* so it responds to the browser then some http requests will come in before JCR commit. Need to make sure to disable the breakpoint for the subsequent threads not to stop. 10. Then 'resume' the debugger ===== Does the above explanation meet the steps you executed?
Created attachment 891016 [details] slowDB.rule
Created attachment 891017 [details] jsf2-rf4-hello-world-portlet.war
Here is another reproduce step which is easier. 1. Start RHJP 6.1.1 2. Build and deploy jsf2-rf4-hello-world-portlet quickstart. 3. Import jsf2-rf4-hello-world-portlet via Application Registry 4. Add an empty page ([Site Editor]->[Add New Page]) *** It's important to "Add an empty page and then edit the page" *** 5. Edit the page ([Site Editor]->[Edit Page]) 6. Drag&Drop jsf2-rf4-hello-world-portlet 7. Apply Byteman and submit slowDB.rule. - bin/bminstall.sh <jboss_pid> - bin/bmsubmit.sh -l slowDB.rule 8. Click Finish icon in portal -> You will see lots of "sleeping 100ms" log in STDOUT -> You will finally see a pop-up "RichFaces is not defined" I attached slowDB.rule and jsf2-rf4-hello-world-portlet.war. slowDB.rule is just emulating slow database so it will result in 'Subsequent http accesses come in before JCR commit'. Vlasta, could you please try this with RHJP 6.1.1? If QE cannot reproduce the issue with released version (6.1.1), this BZ cannot go forward. Thanks! Toshiya
Created attachment 891065 [details] step8exceptions.log Hi *, I've followed the another steps and I got some exceptions in log in step 8 (attaching), but I was not able to see the "RichFaces is not defined" pop-up in my env.
Hmm, I tried various sleep time but cannot reproduce the lock timeout on my side. Could you attach your standalone.xml? Also please give it one more try with 50ms sleep by editing slowDB.rule? Thanks!
Created attachment 891099 [details] standalone.xml I've tried 50ms, but I got lock timeout anyway. Attaching standalone.xml
Thanks Vlasta, I have no idea why it's not reproducible on your side. I will just test when ER2 is out.
Created attachment 895413 [details] 620ER2_after_edit.png
Created attachment 895415 [details] 620ER2_after_edit_and_goto_home.png
I tested with 6.2.0.ER2 and reproduced the issue. The result was the same as DR2. Attached screenshots (620ER2_after_edit.png / 620ER2_after_edit_and_goto_home.png).
Created attachment 895528 [details] RichFaces portlet normal request and response
Created attachment 895529 [details] RichFaces portlet bad request and response (byteman slow DB)
Created attachment 896038 [details] Thread trace in byteman slowDB scenario
Fix send to master and 3.8.x branches.
https://github.com/gatein/gatein-portal/pull/856 was merged in upstream
I was able to perform testing with Byteman without any issues so I consider this resolved.