Ok ... now this is strange. I found out that my resource bundle generator needed a small change. The original appended the messages to the messages_en.properties. So the generated output is automatically appended to the stuff checked in in the messages_en.properties from the src/main/resources directory. That sounds sensible.
But when comparing the output of the en with the other languages I could see that these all contain internationalized resources for all of the resources the messages_en.property does after adding the generated ones. I had no idea where they came from. Unfortunately it seems as if the other resources contain values for both the static and the generated properties. That looks really ugly. So if we add a new Problem type, the English properties is extended, but the others have to be manually? Is there a test to demonstrate which other properties need internationalized values? Otherwise I think we could get into serious trouble when running Falcon on a machine with "fr", "jp" or "zh_CN" as locale. Probably the compiler will generate NullPointerExceptions internally and produce nonsense-error messages as it did for me. Chris ________________________________________ Von: Christofer Dutz <christofer.d...@c-ware.de> Gesendet: Mittwoch, 24. Februar 2016 11:27 An: 'dev@flex.apache.org' Betreff: AW: Think I found out, why the falcon integration-tests never succeed when running them Oh gee .. forget what I just wrote ... it's already done that way :-( Chris ________________________________________ Von: Christofer Dutz <christofer.d...@c-ware.de> Gesendet: Mittwoch, 24. Februar 2016 11:25 An: 'dev@flex.apache.org' Betreff: Think I found out, why the falcon integration-tests never succeed when running them Hi, while trying to make the unit-tests run with maven I stumbled over something. I got some crazy errors when running some tests. While tracing them down, I could see that the "problem output" fails cause no format is specified. This is because a NullPointerException occurs in the compiler ... this seems to happen when an error is reported. The stupid thing is that probably this test will run on systems with "en", "fr", "jp" or "zh_CN" language. In my case it's "de_DE" and I get some really nasty NullPointerExceptions ... I think we should harden this code and make "en" the fallback if there is no resource bundle for the current users language. And we do need quite some Null checks in the code ... it currently produces NPE in way to many places. Chris
