[wildfly-dev] WILDFLY 1650

[Brian Stansberry]

On 8/7/13 1:05 PM, Brian Stansberry wrote:
> 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.
>

Never mind; I'd forgotten this stuff doesn't use modular classloading.

> 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