mmm-util-core: GWT and deserialized NlsMessage instances

[hohwille]

I figured out that an NlsMessage received from the server and deserialized on a GWT client, holds a GWT supersourced NlsTemplateImpl that does:

public String translate(Locale locale) { try { return Dictionary.getDictionary(this.name.replace('.', '$')).get(this.key); } catch (ResourceMissingException e) { return translateFallback(e); } }

For regular use-cases there will be no such global JS object that can be used as dictionary. This is only for explicit I18N/L10N of messages created specific for this purpose. Therefore this exception will occur for each localization and also get logged. This is annoying and should be prevented. For deserialization on GWT we would need to hook in and prevent this e.g. by deserializing to a different class (NlsMessagePlain) or by having a transient flag in the super-sourced code that is set on deserialization. I will go for the latter as deserializing to a different class sounds like a source to the next problem.

[hohwille]

The solution can be a lot simpler: NlsMessageFactoryImpl is already super-sourced and does this:

public NlsMessage createDirect(String bundleName, String key, Map<String, Object> messageArguments) { DictionaryContainer dictionaryContainer = getOrCreateDictionaryContainer(bundleName); String message = dictionaryContainer.resolve(key); return create(message, messageArguments); }

This means that the only way that NlsTemplateImpl[WithMessage] gets created in a GWT client is from deserialization. So we can simply strip out this code. We would either have to find a way to

• access the NlsBundle that must be available on the client (would require central registration of all NlsBundles)
• use the localized text from the server The latter approach is IMHO the best one. However for the moment this means that L10N will then not work properly on GWT client as serialized message will always be in root locale. We will fix this on the long run, but I will create a new bug ticket for this and resolve this one first.

[hohwille]

for the record: The comment above was correct. The super sourced variant of NlsTemplateImpl that has been committed for issue #54 that is now solved in a smarter way. In the end this is a leftover. If will add a quickfix as proposed but keep this issue open and then move it to a later milestone.

[hohwille]

In the end the serialization of exceptions and later localization is quite a specific demand. We can further postpone this. If you use it and want to have this solved let us know.

[hohwille]

The actual bug had already been fixed in 6.0.0 so I opened #141 for the enhancement.