So this was a pure-JSF problem then ;)
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3927912#3927912
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3927912
---
This S
Hi
it seams to be the case... the f:view was in the template, we moved it here for
the test's sake.
The "View Transactions" button is the one doing the problem. On the GET request
(when the page is loaded for the first time) a @Factory and @Begin initialize()
is called to initialize the transa
Make sure you don't have more than one f:view, and that the h:commandButtons
are all inside the f:view.
It would help if you actually show the JSF pages.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3927770#3927770
Reply to the post :
http://www.jboss.com/
Hi Gavin,
Just re-checked this again w/ Seam beta 2...
The second request is a JSF Postback triggered by an inside a
. Funny enough s on the same page work properly... Are
these both handled differently?!
We also put the conversation id on the form and one can clearly see that after
pushing
Is the second request a GET request or a JSF postback?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3927286#3927286
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3927286
--
Ok the last was a dead-end, so I am where I was before... the @Factory method
beeing called twice.
Any hints are welcome! Wrong configuration?
Thanks,
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3913095#3913095
Reply to the post :
http://www.jboss.com/in
Hmmm,
could it be that JspStateManagerImpl.saveSerializedView only does save changes
done to the FacesContext when it is called for the first time?
| ...
| if (serializedView == null)
| {
| // first call to saveSerializedView --> create SerializedView
|
Ok I do not know if this is relevant but on the second request (after the
@Factory and @Begin method is called on the the first request) in
org.jboss.seam.core.Manager::restore() the storedConversationId is null and a
new id gets generated (Id.nextId()). In difference on the next request the id
Hi Gavin,
No don't think so, the timeout was set pretty high. I did set it even higher
today:
|
| org.jboss.seam.core.manager.conversationTimeout
| 360
|
|
but with no effect. Plus - if the conversation gets timed out the SFSB should
be destroyed, right? And the brakepoin
Are you sure the conversation did not time out?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3912442#3912442
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3912442
-
10 matches
Mail list logo
