 | Mailing List | | Home | | Forum Home | | JBoss - Java Application Server | | Tomcat - JSP/Servlet container | | Struts - A MVC web framework | | iText - An open source PDF Java Library | | JDOM - JDOM XML Parser | | J2EE - A mailing list for Java(tm) 2 Platform, Enterprise Edition | | JSP - A mailing list about Java Server Pages specification and reference | | J2EE Pattern - An interest list for Sun Java Center J2EE Pattern Catalog | | Servlet - A mailing list for discussion about Sun Microsystem's Java Servlet API Technology | |
Struts & Hibernate
|
|
|
| | | - Double nested conv. deletes parent 's component | - Double nested conv. deletes parent 's component 2007-08-08 - By pdpantages
Back
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, @(protected), 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 @(protected) 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 @(protected) The @(protected)
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]
| @(protected)
| 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 @(protected) and @(protected) 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
__ ____ ____ ____ ____ ____ ____ ____ ____ ____
jboss-user mailing list
jboss-user@(protected)
https://lists.jboss.org/mailman/listinfo/jboss-user
|
|
|
