Bug 973164 - Bugs in CDI conversational scope
Bugs in CDI conversational scope
Status: CLOSED NOTABUG
Product: JBoss Enterprise Portal Platform 6
Classification: JBoss
Component: PortletBridge (Show other bugs)
6.1.0
Unspecified Unspecified
unspecified Severity unspecified
: ER03
: 6.1.0
Assigned To: Ken Finnigan
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-11 08:06 EDT by Petr Mensik
Modified: 2015-07-19 21:00 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-06-26 04:05:38 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker PBR-512 Major Closed Bugs in CDI conversational scope 2013-09-18 23:24:45 EDT

  None (edit)
Description Petr Mensik 2013-06-11 08:06:15 EDT
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:
Comment 1 JBoss JIRA Server 2013-06-12 08:09:56 EDT
Petr Mensik <pmensik@redhat.com> 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.
Comment 2 JBoss JIRA Server 2013-06-18 14:40:46 EDT
Ken Finnigan <ken@kenfinnigan.me> updated the status of jira PBR-512 to Resolved
Comment 3 JBoss JIRA Server 2013-06-18 14:40:46 EDT
Ken Finnigan <ken@kenfinnigan.me> 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.
Comment 4 Petr Mensik 2013-06-19 05:11:00 EDT
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?
Comment 5 Ken Finnigan 2013-06-19 06:46:18 EDT
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.
Comment 6 Petr Mensik 2013-06-21 06:38:09 EDT
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
Comment 7 Ken Finnigan 2013-06-24 13:47:39 EDT
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
Comment 8 Petr Mensik 2013-06-26 04:05:38 EDT
Yes, I've tested it with this configuration and both of the issues are gone, so I am closing this.
Comment 9 JBoss JIRA Server 2013-09-09 14:20:04 EDT
Ken Finnigan <ken@kenfinnigan.me> updated the status of jira PBR-512 to Closed

Note You need to log in before you can comment on or make changes to this bug.