[wildfly-dev] WILDFLY 1650

[Brian Stansberry]

On 8/7/13 12:20 PM, David M. Lloyd wrote:
> 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.
>

Good point. These tests are running two separate ModelControllers from 
two separate versions in the same VM, with the test fixture invoking on 
both and comparing DMR output. There is complexity related to some of 
the core classes (e.g. stuff from the controller module), but I don't 
see why a class from a subsystem module (e.g. ThreadsLogger) should be 
visible to both ModelControllers.

A possible simple solution is to just make ThreadsLogger etc private in 
the module, but even if it's public I don't think the current version's 
org.jboss.as.threads module should be visible to both sides.

> 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.
>


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat