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:
http://tapestry.apache.org/tapestry4.1/usersguide/localization.html So you have pageA with a link changeLanguageLink pointing to listener public pageB changeLanguage(String locale){ this.getRequestCycle().getEngine().setLocale(new Locale(locale)); return getPageB(); }; Conversely you have a similar link in pageB returning pageA. Hope this helps Il 03/02/2011 9.01, Howard Lewis Ship ha scritto: > 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; when I have some time, I'll try and look in the > code and see what turns up. > > On Wed, Feb 2, 2011 at 6:28 AM, Pepijn Schmitz <capt...@chaos.demon.nl> wrote: >> 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 is indeed >> causing problems. >> >> Can you tell me what the correct way of doing this is? Apart from wanting to >> give the users the ability to configure their language in their user >> settings in our application, it is also problematic that the locale that the >> browser provides is often missing the country, and Java often does not use >> correct date, time and number formats if the locale does not include the >> country. >> >> And do you have any idea if this could also the root cause of my original >> problem? I don't really see how, since all this means as far as I can tell >> is that Tapestry will needlessly instantiate pages, but I still don't see >> how a page which still contains values from one session can end up on >> another session. >> >> Kind regards, >> Pepijn Schmitz >> >> On 26-01-11 21:40, Howard Lewis Ship wrote: >>> 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 those lines. >>> >>> On Wed, Jan 26, 2011 at 3:21 AM, Pepijn Schmitz<capt...@chaos.demon.nl> >>> wrote: >>>> 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 >>>> making >>>> a heap dump and analysing it: all application state objects (of closed >>>> sessions) were still in memory, with references from Page classes in a >>>> TapestryKeyedObjectPool! >>>> >>>> I'm pretty sure the Page properties are supposed to be cleaned out at the >>>> end of a request cycle, when the page is returned to the pool, but >>>> apparently for some reason that is not happening! Is this a familiar >>>> problem >>>> to anyone? >>>> >>>> Kind regards, >>>> Pepijn Schmitz >>>> >>>> On 25-01-11 11:59, Koka Kiknadze wrote: >>>>> 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.nl>wrote: >>>>> >>>>>> 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 >>>>>> care of the SSL and forwards the requests to Glassfish over HTTP. I'll >>>>>> look >>>>>> into the possibility that something is going wrong there, although it >>>>>> seems >>>>>> unlikely due to the above reason... >>>>>> >>>>>> Cheers, >>>>>> Pepijn >>>>>> >>>>>> >>>>>> On 11-01-11 19:04, Koka Kiknadze wrote: >>>>>> >>>>>>> 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 >>>>>>> that >>>>>>> proxy could not mess things up). Well, as the performance was >>>>>>> acceptable >>>>>>> even with HTTPS we just left everything as is. >>>>>>> >>>>>>> Hence I'd suggest temporarily requiring HTTPS for the whole site and >>>>>>> if >>>>>>> the >>>>>>> problem disappears, you'll know for sure it's not your application or >>>>>>> tapestry to be blamed. >>>>>>> >>>>>>> Good luck. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Jan 11, 2011 at 8:37 PM, Pepijn >>>>>>> Schmitz<tapes...@chaos.demon.nl >>>>>>>> wrote: >>>>>>> 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. >>>>>>>> >>>>>>>> The problem is that Tapestry 4.1.6 sometimes injects the wrong >>>>>>>> application >>>>>>>> state object on my pages! As you can imagine, this plays havoc with >>>>>>>> my >>>>>>>> application, with users seeing other users' details, or even worse, >>>>>>>> changing >>>>>>>> other users' information! It's a support and security nightmare. >>>>>>>> >>>>>>>> I'm using Tapestry 4.1.6, and I'm using annotations instead of XML >>>>>>>> files. >>>>>>>> My pages all descend from a base class: >>>>>>>> >>>>>>>> public abstract SupplierDNAPage extends BasePage { >>>>>>>> @InjectState >>>>>>>> public abstract SupplierDnaSession getSupplierDnaSession(); >>>>>>>> >>>>>>>> @InjectStateFlag >>>>>>>> public abstract boolean getSupplierDnaSessionExists(); >>>>>>>> >>>>>>>> ... >>>>>>>> } >>>>>>>> >>>>>>>> hivemodule.xml contains the following: >>>>>>>> >>>>>>>> <?xml version="1.0" encoding="UTF-8"?> >>>>>>>> <module id="com.supplierdna" version="0.0.0"> >>>>>>>> <contribution configuration-id="tapestry.state.ApplicationObjects"> >>>>>>>> <state-object name="supplier-dna-session" scope="session"> >>>>>>>> <create-instance class="com.supplierdna.logic.SupplierDnaSession"/> >>>>>>>> </state-object> >>>>>>>> </contribution> >>>>>>>> ... >>>>>>>> </module> >>>>>>>> >>>>>>>> SupplierDNA is the name of the company I'm writing this for. As I >>>>>>>> understand it, this is the correct way of using application state >>>>>>>> objects. >>>>>>>> And most of the time, it works perfectly. When testing locally I have >>>>>>>> no >>>>>>>> problems with wrong application state being injected, and our demo >>>>>>>> system >>>>>>>> also doesn't have the problem. >>>>>>>> >>>>>>>> The problems seem to start when the server is heavily loaded. Then, >>>>>>>> sometimes, getSupplierDnaSession() will return an application state >>>>>>>> object >>>>>>>> from a different session!!! >>>>>>>> >>>>>>>> I have verified this by adding a pageBeginRender() listener method to >>>>>>>> the >>>>>>>> base class, and a client address property to the session. The >>>>>>>> listener >>>>>>>> method checks whether the client address stored on the session it >>>>>>>> gets >>>>>>>> from >>>>>>>> Tapestry is the same as the client address from the current request, >>>>>>>> and >>>>>>>> throws an exception if this is not the case. On our production >>>>>>>> server, >>>>>>>> this >>>>>>>> happens dozens of times a day! >>>>>>>> >>>>>>>> The method also directly retrieves the application state object from >>>>>>>> the >>>>>>>> HttpSession and compares it to the one it got from Tapestry, and it >>>>>>>> turns >>>>>>>> out that the application state object on the HttpSession is the >>>>>>>> correct >>>>>>>> one, >>>>>>>> but somehow Tapestry is injecting a different one! This seems to rule >>>>>>>> out >>>>>>>> the web container as being the culprit (which is Glassfish 2 update >>>>>>>> 2, >>>>>>>> in >>>>>>>> this case). >>>>>>>> >>>>>>>> Obviously this is a complex problem with a potentially huge number of >>>>>>>> contributing factors, but first I'd just like to know whether this >>>>>>>> sounds >>>>>>>> familiar to anyone? Is there a known problem with Tapestry which >>>>>>>> could >>>>>>>> cause >>>>>>>> this? Has anyone ever experienced something similar? Many thanks in >>>>>>>> advance >>>>>>>> for any help you can give me! >>>>>>>> >>>>>>>> Kind regards, >>>>>>>> Pepijn Schmitz >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>>>>>>> For additional commands, e-mail: users-h...@tapestry.apache.org >>>>>>>> >>>>>>>> >>>>>>>> >>>> >>> >> >> > > -- ================================================== dott. Ivano Mario Luberti Archimede Informatica societa' cooperativa a r. l. Sede Operativa Via Gereschi 36 - 56126- Pisa tel.: +39-050- 580959 tel/fax: +39-050-9711344 web: www.archicoop.it ================================================== --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
