[resteasy-dev] i18n issues?
Ron Sigal
rsigal at redhat.com
Sat Sep 3 12:18:49 EDT 2016
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>. 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.
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.
-Ron
On 09/02/2016 06:51 PM, Alessio Soldano wrote:
> 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 at 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 at 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 at 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 at 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/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
>>>>
>
--
My company's smarter than your company (unless you work for Red Hat)
More information about the resteasy-dev
mailing list