Question

we currently experience some file writing/encoding problems that we cannot reproduce.
Actually there are 2 problems which might have the same cause:

1) We have an application (or better multiple instances of the same app) that uses a velocity template to create a css file on user request. However, in some instances of that application (running on the same server, using the same libraries in the same versions) prepend some stange characters to the CSS string which is written to the file (it’s not a UTF-8 byte order mark).

2) Another application recently delivered a Javascript file (located in the EAR) with junk characters appended. Most of the time the same application delivers that Javascript file correctly, and we could not reproduce that behavior yet. A guess would be that the file which is written to the server’s temp folder is corrupted somehow.

Both applications have the fact in common that junk characters are added to a file so it might be the same or a similar cause.

However, as I said before, we’re unable to reproduce that behavior on our test or development machines and we have no idea what could be the cause (we’ve already checked the file encoding which is set to UTF-8).

Here’s some more information on the system:

OS: Debian GNU/Linux 5.0.4 (lenny)
JBoss: 4.2.3.GA
Java: SUn JDK 1.5.0_17-b04

Any idea what could be going on or what we could look for?

Thanks in advance.

Edit:

Part of the code for problem 1)

...
FileWriter fw;
try
{
  String path = tConfigProperties.getProperty( VELOCITYPATHPARAM );
  fw = new FileWriter( path + VELOCITYFILEPARM );
  fw.write( sw.toString() );//sw is a StringWriter passed to velocity for template processing
  fw.close();
}
catch( IOException e )
{
  //handle exception and display error message
}

Problem 2) can’t be a problem with our Java code, since all we do is link the Javascript in the JSP.

Answer 1

I would look into the possibility that your code is reading / writing the file using a byte buffer, and not taking account of the value returned by the read(byte[]) calls. (It sounds pretty basic, but I recently saw an SO question where this was the root problem.)