2) is an absolute must. That's why the FacesServlet releases the FacesContext at the end of each request. Martin, are you bypassing the FacesServlet?
On 12/5/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote:
Hi Martin! > java.lang.IllegalStateException: Null request object > org.apache.catalina.connector.RequestFacade.getAttribute(RequestFacade.java:256) > > org.apache.myfaces.context.servlet.RequestMap.getAttribute(RequestMap.java:44) > > org.apache.myfaces.context.servlet.AbstractAttributeMap.get(AbstractAttributeMap.java:91) > > org.apache.myfaces.custom.conversation.ConversationManager.getConversationContextId(ConversationManager.java:202) > > org.apache.myfaces.custom.conversation.ConversationManager.getConversationContext(ConversationManager.java:330) > > org.apache.myfaces.custom.conversation.ConversationManager.attachPersistence(ConversationManager.java:503) > Yea - maybe I got it. Is it true that we do NOT release (set to null) the thread-local FacesContext._currentInstance after the request? Tomcat do not create new threads, thus - no one will release 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 see two ways to fix it: 1) avoid using the FacesContext at this point. I can do it, but I would not really like it to do. 2) release the FacesContext at the end of the request. I'd go for 2. Ciao, Mario
-- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces