Community
Participate
Working Groups
Using the same key for different entry-points and servlet names leads to problems. If a user starts different entry-points from the same browser (this means the settingstore cookie is reused), the same settingstore is provided for both. The generated key should take this into account. Maybe it would be also a better approach to let the key be generated by RWT and not by the settingstore implementation.
Today I've checked the current status of this issue with RAP 2.1. I've tested with two scenarios: a) RWT application with two entry points running in the same browser accessed by: http://127.0.0.1:8080/foo/hello-1 http://127.0.0.1:8080/foo/hello-2 In this case both entry points share the same setting store (same cookie, as context/cookie path is the same). b) Two RWT applications running in the same browser accessed by: http://127.0.0.1:8080/foo/hello-1 http://127.0.0.1:8080/bar/hello-1 In this case the entry points have different setting stores (different cookie, as context/cookie path is different). I think that in both scenarios the behavior is correct and expected.
With the current implementation, persisted data is shared among all entrypoints of the same application. I agree that this is more likely to be the expected implementation. There may be user settings that are not related to the entrypoint, but to the entire application, for example the chosen language, font size, etc. The SettingStore seems like the obvious place to keep those user settings. If different entrypoints of the same application each had their own SettingStore, there was no way to share those settings across entrypoints. When a setting is only related to a single entrypoint, I think it should be prefixed. Since the problem described here affects only the Workbench, I'd suggest to fix this problem by prefixing the keys that the workbench uses to preserve its data. Does that make sense?
