I am experiencing few bugs which occurs during CDI testing 1) If I start conversation by calling method in <f:view mode="preRenderView" /> then it never gets promoted to long-running conversation. 2) If you repeat process of creating conversation, ending it and clicking to some other page, then you will get org.jboss.weld.context.NonexistentConversationException 3) If you try to begin conversation with Ajax method call then the conversation is never promoted to long-running too. So actually only way how to start long-running conversation is in @PostConstruct method right now Steps to reproduce Deploy enclosed war to GateIn and follow steps written on portlets homepage. Document URL: Section Number and Name: Describe the issue: Suggestions for improvement: Additional information: Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Petr Mensik <pmensik> made a comment on jira PBR-512 First and last problem seems to be resolved in ER01 but you will still get org.jboss.weld.context.NonexistentConversationException if you click on some other page after ending the conversation.
Ken Finnigan <ken> updated the status of jira PBR-512 to Resolved
Ken Finnigan <ken> made a comment on jira PBR-512 Petr, Item 2 can be resolved by modifying the link in the template to be: <rich:menuItem action="page_2?faces-redirect=true" label="Click"> <a4j:param name="nocid" value="true" /> </rich:menuItem> which basically tells Weld to ignore the conversation id that is present on the request. The reason this is necessary is because the conversation id that was ended by clicking the button still has its id set as a parameter on the request, due to request parameters being retained by the Bridge. We can force the ignoring of that conversation id in the request, to prevent errors on ended conversations.
Ok, everything is fine with nocid param included in the links. Although it might be nice to give users an option of forcing ignorationg of cid in the requests as you have mentioned. So maybe a param in web.xml could control that?
Not sure there would be benefit to that, as it would mean either ignoring it all the time or never. There are valid situations where you want to keep the conversation open between pages, and would not want to use the param option as above. Just a note on the above, I only added the nocid param to the link that opened the page with nothing on it. I didn't add it to the link to the page with the add/remove buttons on it.
Ok, so let's leave it like that. But I actually found that problems number 1 and 3 are still persisting. It really works on the first time but if you end the conversation and try to start it again, then it never gets promoted to the long-running one. So the steps to reproduce this are 1. Go to page with preRenderView method call 2. Add some items to see that is working 3. Go to some other page 4. Go to preRenderView page again 5. Conversation is not promoted to long-running now you can use same steps for Ajax method call, it has the same behaviour
Petr, I've modified the example portlet you'd created and am now no longer able to reproduce the issues you describe. Here are the notes on what I did: - When using <f:event listener> it needs to be present within the <ui:define name="main"> of page.xhtml, otherwise the listener will never be called. - Rendering the result of a4j:commandButton for either create or end conversation needs to include the menu with the links to different pages, such as: <a4j:commandButton value="create conversation" action="#{pokus.initConversation}" render="formular, :menuForm" /> Note the colon before the id of the menu to signify that the id resides outside the form. - Doing the above two changes means that passing nocid as a parameter on the page links is no longer needed. Essentially the above changes to the example ensure that whenever a conversation is promoted to long running, or demoted to transient, that the portlet URLs generated for pages and commands contain, or have removed, the correct cid representing the current conversation for the page. This is particularly important for ajax calls that do not cause new urls to be generated by default. I'll be updating the documentation to reflect these findings. Please let me know if any of the above issues still persist. If not, I'll close this issue
Yes, I've tested it with this configuration and both of the issues are gone, so I am closing this.
Ken Finnigan <ken> updated the status of jira PBR-512 to Closed