Re: Trouble with new ASO Scope

[Eli Doran <el...@gmail.com>]

Happy New Year

I found it. DirectService calls triggerComponent then renderResponse (of 
course). So, my listeners doing a redirect after their work are totally 
avoiding hitting the ApplicationStateManager.flush() call in 
ResponseRendererImpl.renderResponse() and by the time AbstractEngine 
would call the flush method it's too late to do any good for cookies.

Not sure where the best place is to work in the call to flush. Works if 
you call the flush from ResponseRendererImpl.renderResponse() except 
when DirectService.service()'s triggerComponent() gets a redirect 
exception which avoids the renderResponse() call. For now I just did a 
try-catch around triggerComponent() that calls 
ApplicationStateManager.flush() if a redirect exception is received then 
throws the exception on up.

I'm sure there is a more elegant solution just waiting out there.

We'll see.
~eli

Eli Doran wrote:

> I assume you mean the flush() on ApplicationStateManager which occurs 
> right after cycle.cleanup() in AbstractEngine. That's where I started 
> messing around. Eventually I made it to 
> ResponseRendererImpl.renderResponse(..) where it creates the 
> IMarkupWriter that it closes before exiting. Since the writer will 
> close the response there is no way to add cookies after that. So, if 
> any Cookie state is to be flushed it'd have to be before that writer 
> is closed.
>
> I'm playing with that at the moment but I always need an extra level 
> of understanding because I use the post-redirect-get style and that 
> sometimes adds extra stuff to confuse that path of things for me  :)  
> After my listener is called and returns an ILink a redirect is thrown 
> back out to AbstractEngine to be handled. It calls the 
> ServletWebRequest.forward() that tells the response to send a 
> redirect. This seems to prevent the ApplicationStateManager.flush() to 
> send out cookies with the redirect (if moved into the 
> ResponseRenderer) because the response isn't rendered when a redirect 
> is sent.
>
> Time for another break. I'll look at it more later. Anyone have some 
> more pointers to figure this out? How does the work in 
> ResponseRendererImpl.renderResponse() relate to listener methods being 
> called and redirects caused by the listeners? Hmm, the listener call 
> must be before the call to renderResponse() is made so the redirect is 
> being handled before the renderer has a chance to flush the 
> ApplicationStateManager. Hmm, I'll look at that more later.
>
> ~eli
>
> Howard Lewis Ship wrote:
>
>> I believe I intended the flush() method to be the one that actually
>> writes the cookies out. The intent being to assemble a map of cookie
>> keys and values and write those cookies out inside flush().
>>
>> However, the timing is completely wrong!  The flush() is called even
>> aftter the request cycle is cleaned up, far too late.  It should occur
>> from inside the ResponseRenderer service.  Please add a bug.
>>
>> On 12/30/05, Eli Doran <el...@gmail.com> wrote:
>>  
>>
>>> To add more info...
>>>
>>> I added a bit to make sure it was the timing. I set the cookie scope
>>> manager into a cart subclass and when done using it in the listener
>>> method i called the manager's store method on it. Of course store gets
>>> called again by the system a bit after but by then the cart is not 
>>> dirty
>>> and so it returns without doing any store stuff. However, the store
>>> works when run earlier than the system defined time. Any way to 
>>> alter that?
>>>
>>> So, where to dig to find what handles calling store on the
>>> StateObjectPersistenceManagers? I'll look more tomorrow but if anyone
>>> has some thoughts on this I'd be interested in hearing it.
>>>
>>> ~eli
>>>
>>> Eli Doran wrote:
>>>
>>>   
>>>
>>>> I've been trying to setup a new scope for ASO's using cookies. I have
>>>> the ASO working fine and injecting into pages.
>>>>
>>>> The problem is by the time the system calls
>>>> StateObjectPersistenceManager#store for the cookie manager it seems to
>>>> be too late to add cookies to the outgoing response. I checked it
>>>> wasn't the ASO by setting a simple cookie like:
>>>> cookieSource.writeCookieValue("store", "value"); in the store method
>>>> and it doesn't get stored. I'm using CookieSource injected into the
>>>> cookie ASO manager.
>>>>
>>>> Does anyone see a way around this problem? Or am I getting it wrong
>>>> somehow?
>>>>
>>>> Checking through my logs it shows the listener method beginning, the
>>>> cookie scope manager being accessed where it sets a test cookie,
>>>> creates the ASO and returns it, work in the listener is done and the
>>>> listener method returns, then the cookie scope manager is called to
>>>> store the ASO, which it runs through writing another simple cookie as
>>>> well as the ASO cookie and returns and finally the servlet's service
>>>> method completes. The test cookie in the "get the ASO" method is
>>>> available in the browser but the cookies written during the "store the
>>>> ASO" are not. This seems to prevent the possibility of a working
>>>> cookie ASO scope.
>>>>
>>>> I managed to setup a property persistence strategy that persists the
>>>> property object to a Cookie which manages to do the storing in time.
>>>> This works fine but when that object needs to be available to multiple
>>>> pages it'd be nicer to use an ASO than load the page with the
>>>> persistent property whenever it is needed.
>>>>
>>>> What'd you think?
>>>>
>>>> ~eli
>>>>
>>>>
>>>> This is my log...note the empty 'object' value for CookieScopeManager
>>>> on line #7 is an empty cart whose toString() produces an empty string.
>>>>
>>>> 1. 2005/12/31 01:26:46.531  TRACE [http-8888-Processor5]
>>>> TapestryServlet >>> service(ServletRequest, ServletResponse)
>>>> 2. 2005/12/31 01:26:57.171  TRACE [http-8888-Processor5] ReleasePage
>>>>     
>>>>
>>>>>>> doAddToCart()
>>>>>>>           
>>>>>>
>>>> 3. 2005/12/31 01:26:57.328  TRACE [http-8888-Processor5]
>>>> CookieScopeManager >*< CookieScopeManager()
>>>> 4. 2005/12/31 01:26:57.359  TRACE [http-8888-Processor5]
>>>> CookieScopeManager >>> get(String,StateObjectFactory)
>>>> 5. 2005/12/31 01:26:57.359  DEBUG [http-8888-Processor5]
>>>> CookieScopeManager === objectName = cart
>>>> 6. 2005/12/31 01:26:57.359  DEBUG [http-8888-Processor5]
>>>> CookieScopeManager === factory = <SingletonProxy for
>>>> website.state.CartBuilder(org.apache.tapestry.engine.state.StateObjectFactory)> 
>>>>
>>>>
>>>> 7. 2005/12/31 01:26:57.406  DEBUG [http-8888-Processor5]
>>>> CookieScopeManager === object =
>>>> 2005/12/31 01:26:57.406  TRACE [http-8888-Processor5]
>>>> CookieScopeManager <<< get(String,StateObjectFactory)
>>>> 2005/12/31 01:26:58.000  TRACE [http-8888-Processor5] ReleasePage <<<
>>>> doAddToCart()
>>>> 2005/12/31 01:26:58.015  TRACE [http-8888-Processor5]
>>>> CookieScopeManager >>> store(String,Object)
>>>> 2005/12/31 01:26:58.015  DEBUG [http-8888-Processor5]
>>>> CookieScopeManager === objectName = cart
>>>> 2005/12/31 01:26:58.015  DEBUG [http-8888-Processor5]
>>>> CookieScopeManager === stateObject = 204-205_2-206_3
>>>> 2005/12/31 01:26:58.015  DEBUG [http-8888-Processor5]
>>>> CookieScopeManager === dirty = true
>>>> 2005/12/31 01:26:58.031  DEBUG [http-8888-Processor5]
>>>> CookieScopeManager === cookieValue =
>>>> ZH4sIAAAAAAAAAFvzloG1uIhBMjk/Vy81JzMlvygxTy85sahEzzexwBlI/2FkOxfCUirPw8BQUVDOwsDAwAxUL5iVWJaol5OYl67nmVeSmp5aJPRowZLvje0WTAyMngysZYk5pakVRQwCCHV+pblJqUVta6bKck950M0EMg5o2BmwkYzFhQx1DEAxhrNgPhOcf66cA2TlfyCoAAAIrQA+rAAAAA== 
>>>>
>>>>
>>>> 2005/12/31 01:26:58.031  TRACE [http-8888-Processor5]
>>>> CookieScopeManager <<< store(String,Object)
>>>> 2005/12/31 01:26:58.031  TRACE [http-8888-Processor5] TapestryServlet
>>>> <<< service(ServletRequest, ServletResponse)
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>>>
>>>>
>>>>     
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>>
>>>
>>>   
>>
>>
>>
>> -- 
>> Howard M. Lewis Ship
>> Independent J2EE / Open-Source Java Consultant
>> Creator, Jakarta Tapestry
>> Creator, Jakarta HiveMind
>>
>> Professional Tapestry training, mentoring, support
>> and project work.  http://howardlewisship.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>
>>
>>  
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org