we should release it.
For the above case it looks like the the conversation tag sees a
previous instance of the FacesContext which holds a RequestMap which is
no longer valid.
I see two ways to fix it:
1) avoid using the FacesContext at this point. I can do it, but I would
not really like
Hi,
I'm using the conversation tag on a jsp-page like this:
s:startConversation name=pageDemand/
s:conversation value=#{documentBean} name=pageDemand/
and am encountering the following stack-trace on postbacks (not on the
first request) of pages which
a
ThreadLocal - any ThreadLocal will hold its value and presents this
value to other subsequent requests.
Not only for GC we should release it.
For the above case it looks like the the conversation tag sees a
previous instance of the FacesContext which holds a RequestMap which is
no longer valid.
I
requests.
Not only for GC we should release it.
For the above case it looks like the the conversation tag sees a
previous instance of the FacesContext which holds a RequestMap which is
no longer valid.
I see two ways to fix it:
1) avoid using the FacesContext at this point. I can do it, but I would
Hi guys,I created a page that can process more than 100 subscriptions in some circunstances, the conversation stuff can handle this situation with sucess?-- Yours truly (Atenciosamente),
Rogério
Hi!
I created a page that can process more than 100 subscriptions in some
circunstances, the conversation stuff can handle this situation with
sucess?
The conversation tag do not do something more magic than to provide a
new scope which is demarcated by startConversation and endConversation.
So
6 matches
Mail list logo
