Details
-
Type:
Bug
-
Status: Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: 1.8.2-EE-GA_P01
-
Fix Version/s: None
-
Component/s: Framework
-
Labels:None
-
Environment:ICEfaces
Description
SettableLocaleViewRoot is implemented by inspecting the stack to accept the locale only from certain callers:
public void setLocale(Locale locale) {
//ignore locale set by RestoreViewPhase since it is using the first locale in the Accept-Language list,
//instead it should calculate the locale
StackTraceElement[] ste = (new RuntimeException()).getStackTrace();
This approach is performance intensive and should be revised.
public void setLocale(Locale locale) {
//ignore locale set by RestoreViewPhase since it is using the first locale in the Accept-Language list,
//instead it should calculate the locale
StackTraceElement[] ste = (new RuntimeException()).getStackTrace();
This approach is performance intensive and should be revised.
Activity
| Field | Original Value | New Value |
|---|---|---|
| Salesforce Case | [] | |
| Fix Version/s | 1.8.2-EE-GA_P02 [ 10226 ] | |
| Fix Version/s | 1.8.3 [ 10211 ] | |
| Assignee Priority | P3 |
| Assignee | Ted Goddard [ ted.goddard ] |
It's also very possible that this code is no longer necessary at all – removing the stack trace check allowed component showcase to change locales on tomcat with no problems.
Show
Ted Goddard
added a comment - It's also very possible that this code is no longer necessary at all – removing the stack trace check allowed component showcase to change locales on tomcat with no problems.
Since we don't have a firm understanding of the regression risk associated with removing this logic, and that it would require some substantial effort to create reasonable tests to ascertain the actual risk, and also that there is no obvious way to implement the existing logic using a more performant technique, I am moving this out of P02 for time/resource constraint reasons.
Show
Ken Fyten
added a comment - Since we don't have a firm understanding of the regression risk associated with removing this logic, and that it would require some substantial effort to create reasonable tests to ascertain the actual risk, and also that there is no obvious way to implement the existing logic using a more performant technique, I am moving this out of P02 for time/resource constraint reasons.
| Salesforce Case | [] | |
| Fix Version/s | 1.8.2-EE-GA_P02 [ 10226 ] | |
| Fix Version/s | 1.8.3 [ 10211 ] | |
| Assignee Priority | P3 |
| Assignee | Ted Goddard [ ted.goddard ] |
Perhaps there is a way to use a PhaseListener here?