Special characters (UTF-8 encoded or unicode-escaped) in tree grids, labels

Vaadin 6 / 7 / 8
1

Hi,

we have an issue with Vaadin 8 (was also there in Vaadin 7) for which I couldn’t find a solution somewhere in the forum. When displaying strings on some UI elements (e.g. tree grid leaves, labels), after opening the respective window/panel, special characters are not shown correctly, but with the replacement character \uFFFD (a white question mark with black background). For elements which allow interaction, e.g. tree grid leaves, after the first interaction like opening the leave, the character is displayed correctly.


It doesn’t matter whether the strings are read from property files (where we have all special characters as unicode escape sequences) or from a database (which is configured to use UTF-8 encoding). The behavior is the same for different Web browsers (Chrome, Firefox, Edge).

Is there a way to display such characters correctly?

An additional hint: I have observed a very long Vaadin error message which starts with something like “Invalid JSON” when opening dialogs with special characters. But this only happens one time after starting up the server.

When the issue happens, an exceptions occurs and can be seen in the server’s log file:

2020-12-10T09:31:17,375 | WARN  | Atmosphere-Shared-9 | TrackMessageSizeInterceptor      | 200 - com.vaadin.external.org.slf4j - 1.6.1 | Cannot decode the response bytes for 43e22c0e-9c09-4eb4-b17d-36baf6c95e46. Writing the message as it is
java.nio.charset.MalformedInputException: Input length = 1
       at java.nio.charset.CoderResult.throwException(CoderResult.java:281) ~[?:1.8.0_275]

        at java.nio.charset.CharsetDecoder.decode(CharsetDecoder.java:816) ~[?:1.8.0_275]

        at org.atmosphere.client.TrackMessageSizeInterceptor$Interceptor.transformPayload(TrackMessageSizeInterceptor.java:148) [!/:2.4.30.vaadin1]

        at org.atmosphere.cpr.AtmosphereInterceptorWriter.invokeInterceptor(AtmosphereInterceptorWriter.java:81) [!/:2.4.30.vaadin1]

        at org.atmosphere.cpr.AtmosphereInterceptorWriter.write(AtmosphereInterceptorWriter.java:69) [!/:2.4.30.vaadin1]

        at org.atmosphere.cpr.AtmosphereInterceptorWriter.write(AtmosphereInterceptorWriter.java:64) [!/:2.4.30.vaadin1]

        at org.atmosphere.cpr.AtmosphereResponseImpl$Stream.write(AtmosphereResponseImpl.java:957) [!/:2.4.30.vaadin1]

        at org.atmosphere.handler.AbstractReflectorAtmosphereHandler.onStateChange(AbstractReflectorAtmosphereHandler.java:155) [!/:2.4.30.vaadin1]

        at com.vaadin.server.communication.PushAtmosphereHandler.onStateChange(PushAtmosphereHandler.java:52) [!/:8.10.3]

        at org.atmosphere.cpr.DefaultBroadcaster.invokeOnStateChange(DefaultBroadcaster.java:1037) [!/:2.4.30.vaadin1]

        at org.atmosphere.cpr.DefaultBroadcaster.prepareInvokeOnStateChange(DefaultBroadcaster.java:1057) [!/:2.4.30.vaadin1]

        at org.atmosphere.cpr.DefaultBroadcaster.executeAsyncWrite(DefaultBroadcaster.java:871) [!/:2.4.30.vaadin1]

        at org.atmosphere.cpr.DefaultBroadcaster$2.run(DefaultBroadcaster.java:474) [!/:2.4.30.vaadin1]

        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:1.8.0_275]

        at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:1.8.0_275]

        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_275]

        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_275]

        at java.lang.Thread.run(Thread.java:748) [?:1.8.0_275]

Regards

Jochen

18493479.jpg
18493482.jpg

2

It is really hard to say at the quick glance what it is about. I have never seen this myself and I would claim that it is not a problem happening in Vaadin. However there is something similar reported in Atmosphere library’s issue tracker. But also there it is commented that it is hardly Atmosphere issue, but something in system configuration being wrong.

https://github.com/Atmosphere/atmosphere/issues/1203

There is also one isolated report here, which may be related, but could be something else too, as it lacks sufficient detail.

https://github.com/vaadin/framework/issues/9679

3

Finally I found some time to check this. Our UI class still had STREAMING configured for push. Now removed, so it uses the default push transport technology. Possibly solved by this - I’ll have to observe that for some time, because the issue was not always reproducible.