I stumbled in a weird problem in which the same report generated in one server is different from the one generated on another server.
The package deployed (WAR file) is the same, I checked event the MD5 of it. The same data is being used to generate the report, so no difference from the application itself.
I took a look into the Java version and the one that is generating the report as expected is using Oracle JVM 1.7 and the one generating the weird formated report is using OpenJDK.
I suppose this should be the problem right? In this case what else could I check to maybe find the problem?
Things I already have checked are:
war file deployed to both servers;
fonts installed on both servers are the same;
version of both servers (right one is being run on a apache-tomcat-7.0.28 and the weird one apache-tomcat-7.0.29);
properties and version of libraries;
ADD
Within the report I have a few fields that are justified, and these are stretched and line break is positioned in a quite strange position.
For example the blue area should present 2 lines, but it presents 3, the second is the word with a big letter spacing and a 3rd one with just one word that should be on the second line. And the green area is presenting 2 lines which is fine but the last line it is justifying the word to the entire line increasing the space between the letters.
I recheck all the configuration and components and here is the result:
upgrading locally tomcat to 7.0.29 didn't solved the problem;
fonts configured are exactly the same;
font visually resulted in both PDF files are the same;
no log output from JR that could indicate something is missing / wrong;
war file (deployment package) is the same (lib are the same);
server configuration are the same;
What was missing is to change the JVM, and indeed changing JVM from OpenJDK 1.6.0-b09 to Oracle JVM 1.7.0_25-b15 solved the problem.
Related
So, at my job, I've got a ticket to fix a bug that I'm not really sure is fixable. So, here's the deal:
Our application is a java Swing app that configures the under-the-hood engine that runs. All of our machines at the office are Macs, but to ensure cross-platform functionality we frequently do things in Windows VMs.
So, the guy who reported this, is working in his Windows VM using VirtualBox. He copies some text from our application in the Windows VM to our application in Mac. Our application saves its state in XML configuration files. When he then saves the changes, the text in the XML config file has a "?" character where the FEFF control character was.
Now, I've been going over our code. The paste operation drops the code into a JTable with a custom CellEditor, but the cell editor has nothing special regarding copy/paste operations. Literally no code whatsoever on that issue.
When the application then goes to write everything to the XML configuration file when it saves, it uses the org.w3c.dom.* libraries (the standard Java XML libraries) to do it. Again, can't see anything special here.
My gut says that this might not be solvable, that it might just be an issue from copying between VMs, something is getting weirdly corrupted. Anyone else ever encounter something similar or have an idea on this?
I really don't have any code samples to paste here, but anything anyone could ask for I'll try to provide.
Pretty desperate for help after 2 days trying to debug this issue.
I have some text that contains unicode characters, for example, the word:
korte støvler
If I run code that writes this word to a file on one of the problem machines, it works correctly. However, when I write the file exactly the same way in a storm bolt, it does not encode correctly, and the ø character is replaced with question marks.
In the storm_env.ini file I have set
STORM_JAR_JVM_OPTS:-Dfile.encoding=UTF-8
I also set the encoding as UTF-8 in the code, and in mvn when it is packaged.
I have run tests on the boxes to check JVM default encodings, and they are all UTF-8.
I have tried 3 different methods of writing the file and all cause the same issue, so it is definitely not that.
This issue was fixed by simply build another machine on ec2. It had exactly the same software versions and configuration as the boxes with issues.
I'm writing an application that reads a text file containing a list of vocabulary words in both English and Chinese. These are then displayed in a JTable. When I run or debug the app in Eclipse, everything displays fine. I can see and read the characters and the English. However, when I execute the app from the command line or from an executable jar, it's all wrong. The characters show up as either squares or as gibberish.
I also have a text box that when I type Chinese into it, it displays correctly.
My first thought was that it was a font problem. I was using a font installed on my system. Since I can't guarantee that the person using this app will have that font, I moved it to a resource folder and load the font from a file. The font appears as though it's been loaded so I'm convinced it's not a font issue.
I found another question that suggested using -Dfile.encoding=utf-8. I've tried this and it did not work.
Would the brilliant folks at Stack Overflow have any advice on how to make this work?
I'm writing this on a non-chinese version of Windows.
Well then you won't ever be able to get a Java program to produce Chinese command-line output.
Java, like almost all languages, uses the C standard library which has byte-based IO. The Windows command prompt interprets byte-based IO using the locale-specific default code page. That's never a UTF, so Unicode characters outside of the current locale's default code page just won't work.
(In theory you should be able to get it to work by changing your console fonts and using chcp 65001 (UTF-8) together with -Dfile.encoding=UTF-8, but in practice it doesn't work reliably due to bugs in the C runtime. Unicode on the command prompt is a long-standing sore point.)
I'm generating a pdf report with Jasper Reports 3.1.2. I have a multi line text field that contains several lines: this field is split over 2 consecutive pages.
The problem is that on AiX and Linux systems the last line in the first page is always missing (on Windows systems everything is fine). I've tried modifying margins, sizes and fonts but nothing happens: the last line of the first page is always missing
Any idea?
Thanks in advance
What font are you using? Problems like this are usually† caused by fonts not being available. Use font extensions to ensure that you know what font is being used, and then it should render well everywhere.
Also make sure to set this in jasperreports.properties:
net.sf.jasperreports.awt.ignore.missing.font=false
That's great for testing since it catches missing fonts immediately.
†By "usually" I mean "so often that it's indistinguishable from always". But of course it's theoretically possible that there is some other source in this case.
We use Jetty to deliver some js, css and html files, together with a jersey-powered REST API. I have a user running windows 7 32bit, German locale, that is encountering a very strange problem.
One of the js files is very large, about 14 000 LOC. When that file lands in the browser, somewhere along the way, it's been mangled. Specifically, 3981 lines of code has been moved from the middle of the file (at character no 370841, which is at line 9158), to the top of the file. This of course renders the file completely useless.
I have been unable to replicate this in other windows 7 32bit German installs, and I am running out of ideas as to what could be the cause of this.
I'm imagining that perhaps this is some limitation in file sizes that I am somehow hitting, but I'm not knowledgeable enough in Windows configurations to say where I should dig for more info.
Any ideas?
It turns out the problem was a firewall (ZoneAlarm) on the failing windows machines. I guess there is a limit to the size of HTTP packets it can handle or something.. Disabling ZoneAlarm solved the problem.
I'm gonna file a bug report with them.