[jboss-user] [JBoss Seam] - Double nested conv. deletes parent's component

pdpantages do-not-reply at jboss.com
Wed Aug 8 19:34:21 EDT 2007


Seam 1.2.1.GA

Hello Forum,

I have run into another oddity with nested conversations, when I try to nest more than 1 deep.

Any ideas on this will be appreciated.... 

I have conversation stack like this:

[3,2,1] (contains component editorBean3)
[2,1]  (contains component tableBean2,dataModel2)
[1] (contains tableBean1,dataModel1)

The editor and table beans are all SFSB, @Conversational, scope
CONVERSATION.

The Seam debugger shows the above objects in the correct
context/conversation after I start the two nested conversations.

Conversation [2] is started by an s:link + propagation="nest". 
This link is in a t:dataTable rendered from dataModel1.

Conversation [3] is also started by an s:link + propagation="nest". 
The link is in a t:dataTable rendered from dataModel2.

In the above scenario, when I @End conversation [3], Seam 
destroys tableBean2.  It disappears from the context, but the
dataModle2 is not similarly deleted (verified by Seam debugger).

I was not expecting this; components in conversation[2] should not
be affected by the ending of [3], no?

Notes:

The nested conversations in each case are ended with @End. The @End
action method returns a jsf outcome that returns the browser to the
page from which the "edit" was launched. 

I don't see this same behaviour between [1] and [2]. Begining and
Ending nested conversation [2] does not destory or affect tableBean1.

I have 3 facelet pages that are used for the three cases.

I don't have any conversation related directives in my pages.xml for the
corresponding three views.

There are no references to component tableBean2 by EditorBean3 or by
the facelet/page 3.

Conversation [3] is started from page[2]/Conversaion[2] like so. These
s:links are renderd for each row in a t:datatable. 

  | <s:link 
  |    title="Click to get Alarm details"
  |    value="Details"
  |    styleClass="sortLink"
  |    propagation="nest"
  |    action="#{eventEditor.showEventDetails}" >
  |    <f:param name="seqNum" value="#{alarmRow.sequenceNumber}"/>
  |    <f:param name="ctx" value="servicealarmdetails"/>
  | </s:link>
  | 

Conversation [3] is ended by:

  | <s:link
  |    value="Done"
  |    styleClass="button"
  |    onmouseover="this.className='buttonUp'"
  |    onmouseout="this.className='button'"
  |    onmousedown="this.className='buttonDown'"
  |    onmouseup="this.className='buttonUp'"
  |    action="#{eventEditor.done}">
  | </s:link>
  | 

The editor's done() action just returns a jsfOutcome which returns the browser to page[2]

  | @End
  | public String done()
  | {
  |      if ( log.isTraceEnabled() ) 
  |          log.trace ( traceprefix + "(" +  Conversation.instance().getId() + ") done" );
  | 
  |     return this.jsfOutcome;
  | }
  | 

I have also noticed the following. I don't know if these are significant or not:

When the browser returns to page[2], the s:links in the table are
rendered with the proper cid, but with lrc=false. The seam debugger
and worksapces both contradict this, showing that cid 2 is still a
long running conversation.

The url on page[2] doesn't look right. Initially like:
http://localhost:8080/client/view/fault/servicealarmdetails.seam?cid=6&lrc=true

After Beginning then Ending Conversation [3] and returning to the page it looks like:
http://localhost:8080/client/view/fault/servicealarmdetails.seam?cid=7&parentConversationId=6

I put debug statement in my @Create and @Destory method of the table,
which uses Conversation.getInstance().getId() to print the CID. 

I am not certain if the CID is still valid in the destory method; but CID
(3) is printed from in the tableBean2.destory() method.

I.e., I see my log:
...
tableBean2 (2) Create
...
editorBean3 (3) end
...
...
tableBean2 (3) Destroy




View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4072249#4072249

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4072249



More information about the jboss-user mailing list