[ https://issues.apache.org/jira/browse/TAP5-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12681482#action_12681482 ]
Fernando commented on TAP5-577: ------------------------------- fair. ok. so I'm only left with : "fear of change". :) and allowing us to slowly switch to it, bit by bit, rather than forcing us to do it next time I upgrade :) just to make sure that there really are no issues that we have to deal with ( i do worry about previously generated urls, manually generated urls, javascript, etc ) :) > TAP5-422 changes break persistent locale backwards compatibility. > ----------------------------------------------------------------- > > Key: TAP5-577 > URL: https://issues.apache.org/jira/browse/TAP5-577 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core > Affects Versions: 5.1.0.0, 5.1.0.1 > Reporter: Andy Blower > Priority: Critical > > I think that the changes made in T5.1 for TAP5-422 break backwards > compatibility with T5.0's locale persistence. In T5.0 it was a simple matter > to override the default cookie persistence by creating a custom > implementation of the PersistentLocale service and contributing it to be used > instead of the standard internal T5 implementation. > The TAP5-422 changes broke backwards compatibility because anyone who's > created their own implementation of PersistentLocale, or just wants the 5.0 > cookie persistence behaviour, would have found that it's a lot more work and > involves some heavy changes to Tapestry internals. Now with the recent > changes for TAP5-418 (committed yesterday), the situation had been alleviated > somewhat by allowing the the hard-wired URl locale persistence to be switched > off using a new symbol. > However, I still think that this breaks backwards compatibility in two ways: > 1) By changing the default behaviour of locale persistence so that anyone > relying on the locale persistence behaviour of 5.0 will have to make > non-trivial changes when they upgrade to 5.1 to keep the same operation. > 2) By requiring so much work for anyone wanting to keep the 5.0 cookie > persistence behaviour or define their own custom locale persistence. (In 5.0 > it was easy to figure out and implement a custom locale persistence method) > From my analysis of the changes made by TAP5-422 & TAP5-418, I think anyone > wanting non-URL based locale persistence will need to do the following when > upgrading from 5.0 to 5.1: > 1) Set the ENCODE_LOCALE_INTO_PATH symbol to false. > 2) Create an implementation of PersistentLocale and contribute it to the IOC. > (copied from the standard 5.0 code if the old default cookie persistence is > desired) > 3) Create a custom filter written and created to do the same job as the 5.0 > LocalizationFilter and contribute it to the IOC RequestHandler. This filter > will need to call the LocalizationSetter setLocaleFromLocaleName() method > instead of the old setThreadLocale() method. > My suggested resolution would be to re-instate the 5.0 cookie persistence > (LocalizationFilter & PersistentLocaleImpl) and have the new > ENCODE_LOCALE_INTO_PATH symbol default to false allowing 5.1 to work the same > way as 5.0 out of the box. If the symbol is set to true, then the > LocalizationFilter is disabled (not contributed to RequestHandler) and the > PersistentLocale service will need to just store the locale (not set it in a > cookie) for later use by LinkSourceImpl. > LocalizationSetterImpl.setLocaleFromLocaleName(String localeName) would also > need changing back to overriding the passed localeName if a persistent one > had been set into the PersistentLocale service. There may by a much better > solution than this as I've not spent much time on it, but I though I should > try to be helpful as possible. > (It should be noted that this is purely a product of my analysis of the 5.1 > code, I have not found the time to actually run T5.1 and test this out - I > should be able to do this in about a week and a half, but I'm currently > approaching a major milestone deadline. Hopefully someone else will find the > time to prove or disprove my hypothesis.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.