I have generated a bunch of java-files from a WSDL source. I used Apache CXF 2.6.1 for generating the files.
When I put the code onto our production box that is running jetty and maven and I send a request to the server via the generated java-files it somehow changes the systems/JVM character encoding. The swedish characters å, ä and ö changes into Ã¥, ä, ö.
I can't reproduce this on my own box.
Someone have any idea?
Since version 2.5.4 there is a new command line option -encoding which is not yet documented on the official documentation. But when you call the tool with the help option (-h|-help) you will see the encoding option:
wsdl2java ... -encoding UTF-8 ....
Related
I am seeing an issue with maven using Fbinfer using gitlab pipelines using linux runner
[WARNING] File encoding has not been set, using platform encoding
ANSI_X3.4-1968, i.e. build is platform dependent
[ERROR] /build/app/hello.java [43,43] error: unmappable charater
(0xE2] for encoding US-ASCII
Fbinfer maven command used:
/infer capture -- mvn clean compile
Pure ASCII is 7 bit only, meaning that characters above 127 are illegal. 0xE2 is a hexadecimal representation of 226 which is above 127, hence the error.
You need to tell which encoding system to use when interpreting the bytes. A common choice is ISO-Latin-1 - see https://cs.stanford.edu/people/miles/iso8859.html if it looks right to you
Then change in your Pom to reflect that. Look for “ascii” to see where.
Notice that keeping your project 7-bit clean is a good thing to avoid encoding issues.
I'm using OpenLiberty (automatically downloaded through its maven plugin) and my application is working fine (jax-rs and servlet/jsp outputs are fine).
But the console (and messages.log) output is messy. Here is one example:
[INFORMAıåES] SRVE0253I: [io.openliberty.microprofile.health.3.0.internal] [/health] [HealthCheckServlet]: Destrui?Æo bem sucedida.
(expected is [INFORMAÇÕES] ... Destruição bem sucedida.)
Clearly the messages are being printed as ISO-8859-1 in a UTF-8 capable terminal.
Again, this question is not about the application running inside OpenLiberty container, which is completely UTF-8 and working fine. It is about the console output.
A partially useful workaround would be to change its locale to en-US (so that OpenLiberty's messages wouldn't need any special character). Actually, I'd prefer english error messages, because they are easier to google for.
I already tried LANG=en-US.UTF8, LC_ALL=en_US and LC_MESSAGES=en_US, to no avail.
Project's effective pom.xml already declares <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>. Every file in my project is UTF-8. Project's .editorconfig [*] charset = utf-8 (so vscode creates every new file as utf-8).
I'm using bash MINGW64_NT-10.0-18363 + ConEmu-Maximus5 over Windows 10. LANG defaults to =pt_BR.UTF-8.
UPDATE
I've managed to set locale to en-US by adding
-Duser.language=en to ${server.config.dir}/jvm.options.
To be honest, I did it through liberty-maven-plugin:
<properties>
...
<liberty.jvm.language>-Duser.language=en-US</liberty.jvm.language>
...
</properties>
(and for liberty-maven-plugin itself, I've added -Duser.language=en to MAVEN_OPTS)
Unfortunately, -Dfile.encoding=UTF-8 did nothing.
UPDATE 2
I'm also running OpenLiberty inside an Arquillian driven junit test. Interestingly, when launched by arquillian, OpenLiberty honors the -Dfile.encoding=utf-8 setting.
For arquillian it could be configured through arquillian.xml:
<arquillian ...>
<container qualifier="liberty_managed" default="true">
<configuration>
...
<property name="javaVmArguments">-Dfile.encoding=utf-8</property>
...
</configuration>
</container>
</arquillian>
Or in ${server.config.dir}/jvm.options (as I did before):
-Dfile.encoding=utf-8
My conclusion is that -Dfile.encoding is the right way to approach this issue. But somehow when launched by liberty-maven-plugin it is not honored. I'll take a closer look into its source code.
UPDATED ANSWER: This is configurable via JVM options.
Note that in general the jvm.options file requires you to use a single option per line.
If want to use multiple options and use liberty-maven-plugin properties to configure them you could do something like:
<properties>
<liberty.jvm.arg1>-Duser.language=pt</liberty.jvm.arg1>
<liberty.jvm.arg2>-Duser.country=BR</liberty.jvm.arg2>
<liberty.jvm.arg3>-Dfile.encoding=utf-8</liberty.jvm.arg3>
</properties>
(Note that the arg1,arg2,arg3 suffixes don't really get used except to assign unique Maven project property names, but don't appear in the jvm.options file).
And your terminal program must have support for displaying these characters. E.g. for me using the Git Bash default terminal with default settings on a US/English install, the characters in the above Portuguese language config don't display unless click the Window icon then "Options" and add this:
I am getting this error when trying to build the spring.io/sagan project on GitHub from wiki steps.
java.lang.AssertionError:
Expected: "Spring Tool Suiteâ„¢ Downloads"
but: was "Spring Tool Suite™ Downloads"
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:8)
at sagan.tools.support.ToolsPagesTests.showsAllStsGaDownloads(ToolsPagesTests.java:59)
I have tried building through msyGit bash, and through windows CLI without any difference.
I have tried running the site. It builds to 93%. I can browse the site but the site looks like plain HTML without CSS or images.
I have been told its an encoding issue but how to fix this?
It looks like it expects UTF8 but the encoding is ASCII.
Before building I have also tried to change the windows CLI encoding with the following advice:
Unicode characters in Windows command line - how?
But it has not made a difference. I am running windows 8.1
Not tested, but the problem probably comes from the fact that no encoding has been specified to the compiler for the Java files, and the sagan developers probably use a MacOS or Unix machine, whose default file encoding is UTF8, whereas the default encoding is different on Windows.
I would try adding the following lines to the root build.gradle file, inside the configure(javaProjects) section, after the java plugin has been applied:
configure(javaProjects) {
apply plugin: 'java'
// configure encoding to UTF8:
tasks.withType(Compile) {
options.encoding = 'UTF-8'
}
If that solves the problem, you should file a bug report, or even a pull request to the project.
What must be done so that a Maven plugin outputs unicode characters (think ö, ß, ...) correctly on the windows console?
I've created a svn repositoy on a linux server (Debian) and used a client on a windows machine to check my java sources in.
Now I've set up a Hudson server on a different linux server (Ubuntu) to periodically run tests on my code. But the tests fail with a compiler error:
Error: unmappable character for encoding ASCII
On my windows machine I've used the default encoding Cp1252.
On my svn server I can do a local checkout of my sources and they look good.
On my Hudson server the checkout contains illegal characters.
What are the parameters I have to adjust so that all three systems use a working encoding?
EDIT 2009-10-15:
I changed the default encoding of my Ubuntu system to latin1. Now I can open the checkedout files with an editor and they look good (thanks to #John-T at superuser.com).
But Hudson still complained about unmappable character for encoding ASCII and I found that this is caused by maven. I found an explantion, but the suggested solution didn't work. Now maven tells me that it uses latin1 when copying some resources, but the compiler (not using this setting?) still complains with the same error message.
No, the maven compiler plugin doesn't use the project.build.sourceEncoding property. So you need to configure the file encoding for it (I'd use UTF-8):
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<encoding>UTF-8</encoding>
</configuration>
</plugin>
The first thing to identify is which character is causing the problem. It may be that the broken char can be replaced by some pure-ASCII entity. SVN itself is encoding agnostic: it'll just store byte-for-byte what's passed in.
If Hudson requires 7-bit ASCII, then this is all you can do. Otherwise, find out what Hudson supports and save your files in this format instead. UTF-8 would probaby be the way to go.
I don't think there is a way to change the encoding of a file with SVN. You can set the encoding for a commit message with the --encoding flag, but not the contents of files themselves. Text files are stored in the same format they appear on your local disk. The only conversion is a translation of line endings according to the svn:eol-style property.