This sounds related to another issue I had fixed regarding cookies.
That issue was related to Tapestry not always flushing the IO stream
out soon enough for any written cookies to actually make it back out
to the client. I know I remember hearing other people discuss this in
the past so I didn't hesitate as much to make the changes once I saw
them. (I think there is some thread here somewhere of me talking to
someone from mckesson using cookies in portlets)
I'm guessing that you pageBeginRender header writing logic was broken
by this but I'm not entirely sure it is the safest thing to be doing
anyways. That doesn't mean I'm not willing to discuss it, just that
thinking about it now I like the new behavior more. Things like
writing http headers should probably be done in an area that doesn't
involve rendering, like a listener method / something else. It is
unfortunately probably a tiny "leak" in the abstraction where things
like writing cookies / http headers really can't be done anywhere -
even if the api allows you to call the methods at that point. I'm
really not sure how best to solve this problem for you. I feel like a
dick saying "move it to a listener method or service" but I don't have
any better ideas off the top of my head.
On 1/3/07, Maksym Gryevtsov <[EMAIL PROTECTED]> wrote:
I tried upgrade to 4.1.2 from 4.1.1, but this code has stopped working.
I checked response http headers and my header just disappeared.
Any idea why?
public void pageBeginRender(PageEvent event) {
getResponse().setIntHeader("Refresh", 5);
}
abstract public WebResponse getResponse();
I created a JIRA issue
https://issues.apache.org/jira/browse/TAPESTRY-1222
--
Jesse Kuhnert
Tapestry/Dojo team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
