Ensure wrong Action is not executed after detaching a component (#9806)
Due to action key generation on ActionManager a wrong action
may be executed if the component that fired the wanted action
is already detached.
This patch makes action keys globally unique, simplifying the
approach of #8495 but reusing its tests.
Fixes #5864
Fix RadioButtonGroup selection updates to client (#9749)
This patch provides a simple fix for the majority of issues. There are still issues that should be fixes by refactoring parts of the logic in AbstractSingleSelect.
This patch does not unify the handling of empty values in the TestBench elements of various AbstractSingleSelects.
Fixes #9494
Do full connector tracker cleanup when the session lock is released (#9707)
As there is no "request end" call after invoking UI.access() from a background thread,
the connector map was not earlier properly cleaned afterwards. If you toggled visibility of a
component from the background thread, the tracker state became inconsistent.
If this becomes a performance problem, it could probably be optimized to that cleanup
is done in request end and only at the end of access if not inside a request.
Fixes #9654
Change sendMessage access modifier to protected. (#9622)
This allows extending AtmospherePushConnection, and then doing overriding sendMessage. One use case is to correlate the IP address and the message in the logs.
Use ZoneId rather than ZoneOffset for conversion (#9620)
Use ZoneId rather than ZoneOffset for conversion between model (Date) and presentation of LocalDateTime.
LocalDateToDateConverter (correctly) uses ZoneId, whereas LocalDateTimeToDateConverter (incorrectly) used a ZoneOffset. This fix aligns the two Converter implementations and makes the latter one more robust.
A ZoneOffset is a fixed time difference, e.g., +07:00, whereas a time zone - represented by a ZoneId - is more dynamic, including features like Daylight-Savings Time. A ZoneId returns one or more ZoneOffsets via its ZoneRules method. (ZoneOffsets have trivial ZoneRules that simply return the ZoneOffset.)
Since the date/time being displayed may be from any date on the calendar, the ZoneOffset imposes a negative limitation. Using ZoneId instead gets us past that limitation and allows a more robust set of conversion rules.
Fixes #9594