[wildfly-dev] WILDFLY 1650

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[wildfly-dev] WILDFLY 1650

Emmanuel Hugonnet
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.
Emmanuel
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] WILDFLY 1650

David Lloyd-2
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
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] WILDFLY 1650

Brian Stansberry
In reply to this post by Emmanuel Hugonnet
I suggest if possible this PR be broken into two. As you say, the first
issue affects WF and will hit anyone whose default locale isn't English.
I don't believe the solution to it is controversial, so we might as well
get it fixed without waiting to decide what to do about the second one.

The second issue is the problematic one, but doesn't actually affect
WildFly, since it relates to a feature (non-English messages) that
doesn't exist in WildFly.

On 8/7/13 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.
> Emmanuel
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] WILDFLY 1650

Brian Stansberry
In reply to this post by David Lloyd-2
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
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [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
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev