I recently run into https://issues.apache.org/bugzilla/show_bug.cgi?id=49417
and it reminded me of your case, so take a look, perhaps it's related (assuming
the getLocale() change you mentioned didn't help)
In short, that bug report mentions: when you use mod_proxy to connect to a
backend tomcat
Hi Koka,
Yes, we use it for every request. The application is not even reachable
over port 80. :-)
It seems we found the problem though. It looks like it was caused by
overriding getLocale() in our page base class, although I'm not sure the
problem is 100% gone now, and I don't fully
Well, the idea in Tapestry has ever been that the locale for a page is
fixed, once determined, and it's hard to say what the effect of your
change would be ... but good detective work getting this far.
I don't currently remember where in Tapestry 4.1 the determination of
client locale is made;
In our case we were lucky enough that we can ask user to change language
only on a given page.
So the solution we adopted was to duplicate that page and to have
listeners for changing language that where pointing to the other page.
This because the language is changed only when page is rendered:
Hi Howard,
I know, but I've been through my code with a fine-toothed comb and as
far as I can tell I'm doing everything right. I'm not storing any
references to page objects, and all page objects I use in my code (to
return from listeners) I'm getting from abstract getters annotated with
Hi Howard,
Further to my last message, I just discovered that I was making a faulty
assumption. When the pages are checked out of the pool, the engine
locale is used to build the page key, but when they are released to the
pool, the *page* locale is used! So overriding getLocale() on the page
As your problem persists I dare to get back to my initial response. You said
We're already using HTTPS
Usually HTTPS is used only at the authentication page. Are you sure you have
tested it with HTTPS for every single page?
No, not yet! :-(
Anyone else have any idea?
In short: my Page objects occasionally get the wrong application state
object injected by Tapestry 4.1!
I've been looking into it, but it's very hard to see what's going on
with all the synthetic classes created by Hivemind. But one clue I got
by
It isn't familiar to me. Once possible way things could go awry would
be for you to keep a reference to some page as a property of some
other page ... that can result in data moving into and out of the page
without Tapestry's normal lifecycle to initialize it and clean it out.
I'd look along
Did you find root of the problem? Just curious :)
Good luck
On Tue, Jan 11, 2011 at 11:00 PM, Pepijn Schmitz capt...@chaos.demon.nlwrote:
Hi,
Thanks! But I don't think that's it. We're already using HTTPS, but also
that would not explain how the correct application state object can be on
Hi everyone,
I'm having a bizarre problem with Tapestry, and I'm hoping someone here
might be able to point me to a solution. Before I go into detail I'd
like to describe the problem generally, in the hopes that it might be a
known problem or someone may have encountered something similar.
I did have exactly similar problem couple of years ago - JSF app worked fine
from intranet, but messed up user sessions when accessed from WAN side.
So initial suspect was the squid proxy configuration of our ISP. The problem
disappeared as soon as we turned encryption on for the whole site (so
Hi,
Thanks! But I don't think that's it. We're already using HTTPS, but also
that would not explain how the correct application state object can be
on the HttpSession, even though Tapestry injected the wrong one...
We are using Apache 2 using mod_proxy as a front-end though. Apache
takes
13 matches
Mail list logo
