We are using Tapestry 4.0 for over a year. Since, we were not able to find a reliable (called on every request) and consistent (Information from HttpServletRequest is available through RequestCycle at the time of call) way to initialize and cleanup the pages to achieve behavior quoted from the User Guide below.
We are trying to initialize BusinessBehaviourBean which is stored in the pages instance variable. We want this bean to have a lifecycle of the request. Thus, when page is pulled from the page pool we want to initialize it. Then use it for the duration of the request. Then, clean it up before returning to the page pool. At the time we are initializing this page instance variable we need full access to information from the HttpServletRequest object. That is: request parameters, session objects etc... For example the bean is user specific. Thus we need to know who the user making request is. We tried few approaches: 1. Override prepareForRender(). However, that doesn't always work since prepareForRender() is not always called by the framework. 2. Override attach() and finishLoad(). However, RequestCycle is not available when those are called. This makes HttpServletRequest info not available at this point. At this point servlet container is aware of the request, so it should be made available by API. Can anybody suggest how to do this type of initialization? >>>>>>>>>>>>>>>>>>>>> Quote from User Guide: Servlets, and by extension, JavaServer Pages, are inherently stateless. That is, they will be used simultaneously by many threads and clients. Because of this, they must not store (in instance variables) any properties or values that are specific to any single client. This creates a frustration for developers, because ordinary programming techniques must be avoided. Instead, client-specific state and data must be stored in the HttpSession or as HttpServletRequest attributes. This is an awkward and limiting way to handle both transient state (state that is only needed during the actual processing of the request) and persistent state (state that should be available during the processing of this and subsequent requests). Tapestry bypasses most of these issues by not sharing objects between threads and clients. Tapestry uses an object pool to store constructed page instances. As a page is needed, it is removed from the page pool. If there are no available pages in the pool, a fresh page instance is constructed. For the duration of a request, a page and all components within the page are reserved to the single request. There is no chance of conflicts because only the single thread processing the request will have access to the page. At the end of the request cycle, the page is reset back to a pristine state and returned to the shared pool, ready for reuse by the same client, or by a different client. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]