Concurrent call to conversation in submit event

[faffinito]

Hi, I have a concurrent call to conversation error.
This seems due to the on submit call:

"<s:button id="Save" value="Save" action="{personHome.persist}" onclick="submit();">
<f:param name="comeBack" value="{personHome.comeBack}/>
</s:button>"

I've tried putting every ajax call in an eventsQueue but that didn't work.
When I used the h:commandButton instead of the s:button I hadn't this kind of problem, but I have necessity to use the s:button.

Thanks in advance,

F.

[kragoth]

Out of curiosity why do you feel you have to use the s:button.
As far as I know (this is just from reading as I do not use s:link or button in my project) the s:button does not submit the form, however in your onclick you call a JS function called submit(). Seems to me that a h:button would do exactly what you want you may just need to modify your backend code slightly.

[faffinito]

For some reason with the h:commandButton the parameters specified in f:param are not transmitted. It's another unexplained issue.

[idyoshin]

Fabio Affinito wrote on Dec 15, 2009 12:44:


Hi, I have a concurrent call to conversation error.
This seems due to the on submit call:

"<s:button id="Save" value="Save" action="{personHome.persist}" onclick="submit();">
<f:param name="comeBack" value="{personHome.comeBack}/>
</s:button>"

I've tried putting every ajax call in an eventsQueue but that didn't work.
When I used the h:commandButton instead of the s:button I hadn't this kind of problem, but I have necessity to use the s:button.

Thanks in advance,

F.

You can modify your code to the following:

<h:commandButton id="Save" value="Save" action="{personHome.persist}" >
<f:setPropertyEventListener target="{bean.whereToStoreComeBackValue}" value="{personHome.comeBack}/>
</h:commandButton>

[faffinito]

Hi Ilya,
Thanks for your answer. Unfortunately the result using f:setPropertyActionListener and f:param is the same.

Probably my problem is elsewhere: see here

[blabno]

I think, that your s:button submits form and executes javascript making other connection, which results in two concurrent calls. Do not use s:button in this scenario.

[idyoshin]

Hello Fabio,

I'd like to clarify does your entityHome is CONVERSATION Scoped? or with default- which is EVENT. If it's EVENT scoped you simply lost the previously setted comeBack property.

Regards,
Ilya Dyoshin.

[faffinito]

It actually seems to be conversations scoped.

Temporarily, I'm using this workaround:

     public String getcomeBack() {
          
          if (this.comeBack == null) {
              return this.comeBack = (String) FacesContext.getCurrentInstance()
                           .getExternalContext().getRequestParameterMap().get(
                                   "comeBack");
          } else {
               return this.comeBack;
          }
     }

where in my personEdit.xhtml :

<h:commandButton id="save" value="Salva" action="#{personHome.persist}" styleClass="green left" >
     <f:param name="comeBack" value="#{personHome.comeBack}"/>
</h:commandButton>

pages.xml:

     <page view-id="/personEdit.xhtml" conversation-required="true" no-conversation-view-id="/errorConversationExpired.xhtml">
          <navigation from-action="#{personHome.persist}">
               <end-conversation if="#{conversation.nested}" before-redirect="true"/>
               <rule if-outcome="visitEdit">
                    <redirect view-id="/visitEdit.xhtml" />
               </rule>
               <param name="comeBack" value="#{personHome.comeBack}"/>
          </navigation>
          
     </page>

Regards,

Fabio

[faffinito]

Sorry, I made a mistake in my quotes in the previous message.
By this mistake I found out that the point was the h:commandButton. By replacing commandButton with commandLink there was no need for the workaround and everything works.

F.

[blabno]

This is wrong ! EntityHome (if extending seam framework component) is CONVERSATION scoped by default. It inherits scope annotation, and real default for pojo is overriden.

[faffinito]

In fact, the essential thing was to change the commandButton into a commandLink.