[resteasy-dev] i18n issues?

[Alessio Soldano]

Thanks Ron.
I've thought a bit about this; avoiding copying those resources is not 
easily doable due to classloading issues; so I would propose the changes 
that you can see at https://github.com/resteasy/Resteasy/pull/926 (I 
just modified the resteasy-netty4 module, if we agree on this I can fix 
all other modules). The most important change is to run the resources 
cleanup in prepare-package maven phase, so that a mvn package / mvn 
install / mvn integration-test run does not leave the project "dirty" 
with test resources in the main tree (no need to rely on next mvn clean 
run). On top of that I would refactor all TestMessages_* test into 
I18nTestMessages_* in order to run them in a separate maven surefire 
execution; that way only the i18n tests would need to run in fork mode. 
Afterwards, we could even decide to enable the i18n profile on Travis CI 
runs.
WDYT?

Cheers
Alessio


Il 03/09/2016 18:07, Ron Sigal ha scritto:
> Hi Alessio,
>
>
> On 09/02/2016 06:33 PM, Alessio Soldano wrote:
>> OK, cool, thanks for explanation, now it's a bit clearer to me (and this
>> adds to what Martin was writing in the other thread "Re: RESTEasy
>> providers tests refactoring" few days ago).
>> What is actually tested though? Isn't JBoss Logging generating the
>> needed i18n classes for us?
> Well, yes and no. In the absence of message bundles, JBoss Logging will
> just use the default values in, for example,
> org.jboss.resteasy.resteasy_jaxrs.i18n.Messages in resteasy-jaxrs. If
> you want anything other than the default, you have to create message
> bundle files, and JBoss Logging can create a template bundle file. I
> don't remember the exact mechanism at the moment, but it's how I
> created, for example,
> resteasy-jaxrs/src/test/resources/i18n/Messages.i18n_xx.properties, by
> modifying the template file.
>> Do we really need those tests to cover any
>> i18n message that we add?
> Well, no, not really. Changing
> org.jboss.resteasy.resteasy_jaxrs.i18n.Messages, for examples, would
> change the message bundle template, so one could generate new message
> bundles, but, in fact, I have almost never (or maybe never) done that.
> The tests mostly test the first and last messages, plus a few that
> looked a little special for some reason or other. For example, a message
> with an unusual character, or with more than the usual parameters. So,
> adding a new message, unless it's a new last message, wouldn't affect
> the test. Of course, if a new message is special in some way, it might
> be worth testing. That would require rebuilding the message bundles in
> src/test/resources.
>
> Really, the point of the tests was to make sure i18n was working when I
> first did it. Just adding a new message isn't likely to break it.
>
>> This said, perhaps we can figure out a way to avoid copying test
>> resources into main tree, I might try an alternative approach here by
>> tuning the classloader that's used in the test to load resources, so
>> that it picks them where they are in test area. Will think about it in
>> the future...
>>
>> Cheers
>> Alessio
>>
>> Il 02/09/2016 23:20, Ron Sigal ha scritto:
>>> Hey Alessio,
>>>
>>> Those i18n profiles are used to test logging in the presence of a
>>> non-default locale. In particular, the tests set a locale which brings
>>> in message bundles from src/main/resources. Most of the time, the
>>> bundles live in src/test/resources because they are purely for testing
>>> and shouldn't ship in the jars. Notice the presence of
>>>
>>>>                <plugin>
>>>> <artifactId>maven-clean-plugin</artifactId>
>>>>                    <configuration>
>>>>                        <filesets>
>>>>                            <fileset>
>>>> <directory>src/main/resources</directory>
>>>>                                <includes>
>>>> <include>org/**</include>
>>>>                                </includes>
>>>>                            </fileset>
>>>>                        </filesets>
>>>>                    </configuration>
>>>>                </plugin>
>>> in Resteasy/pom.xml, which cleans up the bundles whenever mvn clean is
>>> executed.
>>>
>>> One other issue, by the way, is the fact that, as far as I can tell,
>>> setting a default locale in a JVM can't be reversed. The i18n tests use
>>> multiple default locales, e.g., "en" and "xx", to bring in different
>>> message bundles, so they need separate JVMs. That's why the i18n
>>> profiles set
>>>
>>>>                        <plugin>
>>>> <groupId>org.apache.maven.plugins</groupId>
>>>> <artifactId>maven-surefire-plugin</artifactId>
>>>>                           <configuration>
>>>> <reuseForks>false</reuseForks>
>>>>                            </configuration>
>>>>                        </plugin>
>>> <reuseForks/> to false.
>>>
>>> These i18n profiles have been sitting there quietly for quite a while
>>> now. They were added mostly to test that I did the i18n conversion
>>> properly. Since then, there hasn't really been any reason to run them,
>>> except, maybe every couple of years, we add a new log message. ;-)
>>>
>>> Or, in Latin, mea culpa. Hope that helps.
>>>
>>> -Ron
>>>
>>> On 09/02/2016 12:15 PM, Alessio Soldano wrote:
>>>> Hi,
>>>>
>>>> while fixing an issue with i18n messages in the Vert.x server adapter
>>>> (basically the same base id of Netty4 adapter was used, hence resulting
>>>> in id clashes), I stumbled upon the i18n maven profile that can be found
>>>> in many pom.xml files in the project. Can anybody please explain
>>>> how/when that is used?
>>>>
>>>> In particular, when that profile is on, I find what the
>>>> maven-resources-plugin does a bit suspicious; see for example
>>>> https://github.com/resteasy/Resteasy/blob/5b4823ff60d73fdf48f7c0b70b2b4ee6a388b863/resteasy-jaxrs/pom.xml#L171-L195
>>>> , files from the test tree are copied into the main tree (hence
>>>> potentially polluting the built artifacts).
>>>>
>>>> Thanks
>>>>
>>>> Alessio
>>>>


-- 
Alessio Soldano
Web Service Lead, JBoss