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/5b4823ff60d73fdf48f7c0b70b2b4ee... > , files from the test tree are copied into the main tree (hence > potentially polluting the built artifacts). > > Thanks > > Alessio >

Btw, afaics we have modules having the i18n profile with that maven-resources-plugin thing, but not having any src/test/resources/i18n stuff: alessio@localhost /ssd/resteasy (master) $ tree resteasy-wadl-undertow-connector/ resteasy-wadl-undertow-connector/ ├── pom.xml └── src └── main └── java └── org └── jboss └── resteasy └── wadl └── WadlUndertowConnector.java 7 directories, 2 files alessio@localhost /ssd/resteasy (master) $ tree providers/fastinfoset/ providers/fastinfoset/ ├── pom.xml └── src └── main ├── java │ └── org │ └── jboss │ └── resteasy │ └── plugins │ └── providers │ ├── fastinfoset │ │ └── i18n │ │ └── Messages.java │ └── jaxb │ └── fastinfoset │ ├── FastInfosetCollectionProvider.java │ ├── FastinfoSetContext.java │ ├── FastinfoSetElementProvider.java │ ├── FastinfoSetJAXBContextFinder.java │ ├── FastInfosetMapProvider.java │ ├── FastinfoSetMarshaller.java │ ├── FastinfoSetUnmarshaller.java │ ├── FastinfoSetXmlRootElementProvider.java │ ├── FastinfoSetXmlSeeAlsoProvider.java │ └── FastinfoSetXmlTypeProvider.java └── resources └── META-INF └── services └── javax.ws.rs.ext.Providers 15 directories, 13 files alessio@localhost /ssd/resteasy (master) $ tree providers/resteasy-validator-provider-11/ providers/resteasy-validator-provider-11/ ├── pom.xml └── src └── main ├── java │ └── org │ └── jboss │ └── resteasy │ ├── api │ │ └── validation │ │ ├── ResteasyViolationException.java │ │ ├── ResteasyViolationExceptionMapper.java │ │ └── ViolationReport.java │ └── plugins │ └── validation │ ├── AbstractValidatorContextResolver.java │ ├── ConstraintTypeUtil11.java │ ├── GeneralValidatorImpl.java │ ├── i18n │ │ ├── LogMessages.java │ │ └── Messages.java │ ├── SimpleViolationsContainer.java │ ├── ValidatorContextResolverCDI.java │ └── ValidatorContextResolver.java └── resources └── META-INF └── services └── javax.ws.rs.ext.Providers 14 directories, 13 files alessio@localhost /ssd/resteasy (master) $ tree providers/multipart/ providers/multipart/ ├── pom.xml └── src └── main ├── java │ └── org │ └── jboss │ └── resteasy │ ├── annotations │ │ └── providers │ │ └── multipart │ │ ├── MultipartForm.java │ │ ├── PartFilename.java │ │ ├── PartType.java │ │ └── XopWithMultipartRelated.java │ └── plugins │ └── providers │ └── multipart │ ├── AbstractMultipartFormDataWriter.java │ ├── AbstractMultipartRelatedWriter.java │ ├── AbstractMultipartWriter.java │ ├── ContentIDUtils.java │ ├── FieldEnablerPrivilegedAction.java │ ├── HeaderFlushedOutputStream.java │ ├── i18n │ │ ├── LogMessages.java │ │ └── Messages.java │ ├── InputPart.java │ ├── ListMultipartReader.java │ ├── ListMultipartWriter.java │ ├── MapMultipartFormDataReader.java │ ├── MapMultipartFormDataWriter.java │ ├── MimeMultipartProvider.java │ ├── MultipartConstants.java │ ├── MultipartFormAnnotationReader.java │ ├── MultipartFormAnnotationWriter.java │ ├── MultipartFormDataInputImpl.java │ ├── MultipartFormDataInput.java │ ├── MultipartFormDataOutput.java │ ├── MultipartFormDataReader.java │ ├── MultipartFormDataWriter.java │ ├── MultipartInputImpl.java │ ├── MultipartInput.java │ ├── MultipartOutput.java │ ├── MultipartReader.java │ ├── MultipartRelatedInputImpl.java │ ├── MultipartRelatedInput.java │ ├── MultipartRelatedOutput.java │ ├── MultipartRelatedReader.java │ ├── MultipartRelatedWriter.java │ ├── MultipartWriter.java │ ├── OutputPart.java │ ├── XopWithMultipartRelatedJAXBProvider.java │ ├── XopWithMultipartRelatedReader.java │ └── XopWithMultipartRelatedWriter.java └── resources └── META-INF └── services └── javax.ws.rs.ext.Providers 16 directories, 42 files which means we are already not testing all log messages. Perhaps we should fix these modules or drop the profiles there. Any thought? Cheers Alessio Il 03/09/2016 00:33, Alessio Soldano ha scritto: > 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? Do we really need those tests to cover any > i18n message that we add? > > 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/5b4823ff60d73fdf48f7c0b70b2b4ee... >>> , files from the test tree are copied into the main tree (hence >>> potentially polluting the built artifacts). >>> >>> Thanks >>> >>> Alessio >>>

Il 03/09/2016 18:18, Ron Sigal ha scritto: > I can think of a couple of circumstances: > > 1. I'm the only person in the universe who knows about Resteasy and > i18n. <evil_laugh>BwaHaaHaa!!!</evil_laugh>. Eheh ;-)

> When I noticed that Weinan > had created resteasy-wadl, for example, I internationalized it. On the > other hand, I never noticed the introduction of > resteasy-wadl-undertow-connector. Well, that actually have now log message for the user. > 2. resteasy-fastinfoset-provider and resteasy-multipart-provider, for > example, DO HAVE src/test/resources/i18n in branch 3.0.x. It looks like > they didn't make it into master branch. Ah, interesting.. didn't notice this. We should copy those resources back from 3.0.x then... Thanks Alessio

Hi, would there be a way to move these i18n tests into the testsuite? It would be better to avoid having two leftover tests in each module.

Martin Stefanko Associate Software Engineer JBoss Sustaining Engineering Team Red Hat Czech s.r.o. On Tue, Sep 6, 2016 at 8:39 PM, Ron Sigal <rsigal(a)redhat.com <mailto:rsigal@redhat.com>> wrote: On 09/05/2016 08:51 AM, Alessio Soldano wrote: > Il 03/09/2016 18:18, Ron Sigal ha scritto: >> I can think of a couple of circumstances: >> >> 1. I'm the only person in the universe who knows about Resteasy and >> i18n. <evil_laugh>BwaHaaHaa!!!</evil_laugh>. > Eheh ;-) By the way, I remembered that I did, in fact, write a bit of documentation about i18n: http://docs.jboss.org/resteasy/docs/3.0.19.Final/userguide/html/I18N.html <http://docs.jboss.org/resteasy/docs/3.0.19.Final/userguide/html/I18N.html... . > > >> When I noticed that Weinan >> had created resteasy-wadl, for example, I internationalized it. On the >> other hand, I never noticed the introduction of >> resteasy-wadl-undertow-connector. > Well, that actually have now log message for the user. > >> 2. resteasy-fastinfoset-provider and resteasy-multipart-provider, for >> example, DO HAVE src/test/resources/i18n in branch 3.0.x. It looks like >> they didn't make it into master branch. > Ah, interesting.. didn't notice this. We should copy those resources > back from 3.0.x then... > > Thanks > Alessio > -- My company's smarter than your company (unless you work for Red Hat) _______________________________________________ resteasy-dev mailing list resteasy-dev(a)lists.jboss.org <mailto:resteasy-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/resteasy-dev <https://lists.jboss.org/mailman/listinfo/resteasy-dev> _______________________________________________ resteasy-dev mailing list resteasy-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/resteasy-dev

Il 07/09/2016 10:11, Alessio Soldano ha scritto: > Il 07/09/2016 10:01, Martin Stefanko ha scritto: >> Hi, >> >> would there be a way to move these i18n tests into the testsuite? It >> would be better to avoid having two leftover tests in each module. > mmh... I'm not 100% sure, it depends on how (classloading) i18n > messages are loaded through jboss logging. I'll try this and let you > know here. As I feared, it does not work, messages end up not being loaded from the testsuite module.

So we'll live with the i18n tests in each module. Cheers Alessio

Hi, would there be a way to move these i18n tests into the testsuite? It would be better to avoid having two leftover tests in each module. Martin Stefanko Associate Software Engineer JBoss Sustaining Engineering Team Red Hat Czech s.r.o. On Tue, Sep 6, 2016 at 8:39 PM, Ron Sigal <rsigal(a)redhat.com <mailto:rsigal@redhat.com>> wrote: On 09/05/2016 08:51 AM, Alessio Soldano wrote: > Il 03/09/2016 18:18, Ron Sigal ha scritto: >> I can think of a couple of circumstances: >> >> 1. I'm the only person in the universe who knows about Resteasy and >> i18n. <evil_laugh>BwaHaaHaa!!!</evil_laugh>. > Eheh ;-) By the way, I remembered that I did, in fact, write a bit of documentation about i18n: http://docs.jboss.org/resteasy/docs/3.0.19.Final/userguide/html/I18N.html <http://docs.jboss.org/resteasy/docs/3.0.19.Final/userguide/html/I18N.html... . > > >> When I noticed that Weinan >> had created resteasy-wadl, for example, I internationalized it. On the >> other hand, I never noticed the introduction of >> resteasy-wadl-undertow-connector. > Well, that actually have now log message for the user. > >> 2. resteasy-fastinfoset-provider and resteasy-multipart-provider, for >> example, DO HAVE src/test/resources/i18n in branch 3.0.x. It looks like >> they didn't make it into master branch. > Ah, interesting.. didn't notice this. We should copy those resources > back from 3.0.x then... > > Thanks > Alessio > -- My company's smarter than your company (unless you work for Red Hat) _______________________________________________ resteasy-dev mailing list resteasy-dev(a)lists.jboss.org <mailto:resteasy-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/resteasy-dev <https://lists.jboss.org/mailman/listinfo/resteasy-dev>

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/5b4823ff60d73fdf48f7c0b70b2b4ee... >>> , files from the test tree are copied into the main tree (hence >>> potentially polluting the built artifacts). >>> >>> Thanks >>> >>> Alessio >>>

On 09/05/2016 08:50 AM, Alessio Soldano wrote: > 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). Sounds good. Don't know why I didn't think of that ...

> 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. I could be wrong, but I think that, in branch 3.0.x, at least, all of the i18n tests would be in org/jboss/resteasy/test/i18n/**. That may not be true after refactoring, though.