[wildfly-dev] WILDFLY 1650

[David M. Lloyd]

On 08/07/2013 12:04 PM, Emmanuel Hugonnet wrote:
> Hi,
> I 'm writting this to try to explain my position on WILDFLY 1650.
> I don't know how to change the PR
> (https://github.com/wildfly/wildfly/pull/4749) to have it intergated.
> Currently I can't build EAP nor Wildfly with all tests on a French
> loacle machine.
> On GNU/Linux I can do it by changing the LANG in my shell but on Windows
> I just had to forget about it.
>
> This problem happens because of the assumption that the default locale
> is English so some messages in tet are using 'hardcoded' string instead
> og I18n message.
> Second, which affects EAP only (but which is still an issue in Wildfly
> even if it is hidden), some tests which check for model
> retro-compatibility will use 'old' version of JBoss AS which contains
> translated logger messages in generated classes. Alas for French you
> have old versions without any French and new with French, because of an
> issue with the classloader we happens to be casting a $Logger to a
> Logger which wasn't loaded by the same classloader.
> I have tried to replicate this behaviour in Wildlfy, using the codehaus
> mojo annotation processor to generate the translated loggers using the
> main source code for the test source code.
>
> While this complicated test maybe too much I think it should be possible
> to make Wildlfy fully buildable on a French Windows computer (even if we
> know Windows sucks and French rules ;o) )
>
> So I'm asking here about how we should tackle this issue.

It sounds to me like the problem doesn't match the solution exactly - 
maybe more of an "XY problem". http://mywiki.wooledge.org/XyProblem

The question I'd ask is, *why* is there more than one (e.g.) 
ThreadsLogger class?  Especially considering that these classes should 
be private to the module which declares them - this is highly suspect to 
me.  The default locale is and should remain US English, but the lack or 
presence of other locales should not have *any* effects like this.  This 
is the real issue that needs investigating.

If our tests are doing this then it's yet another example of poorly 
thought out testing screwing up when even the simplest of parameters change.
-- 
- DML