I think what you're describing is a bug with Acrobat on a certain browser/OS. At least it sounds familiar. If that's true, there's nothing you can do about it. The cure was to have the user download the file and then open the downloaded copy.
The problem seems to be that the attachment went into the temporary downloads directory, but Acrobat was looking either for a different name or a different location, I'm not sure which.
Customer surveys are for companies who didn't pay proper attention to begin with.
Yes, it sounds like relating to Acrobat/MSIE bug. The bug is caused by having spaces in the temporaty folder (like for example TMP="C:\Documents and Settings\User\Temp". The downloaded file is stored in that folder and passed to the acrobat executable in not quoted form, like this: acrobat.exe C:\Documents and Settings\User\Temp\file.pdf
Invoked with such a command acrobat thinks it was passed 3 separate arguments "C:\Documents", "and" and "Settings\User\Temp\file.pdf" and complains about non existing file.
The workaround I am using for that is serve the files from a link. So in my app instead of sending the content type header and the pdf body I am sending html response with the link to generated document. The user then can click on the link and decide whether he wants to open it or save it. Fortunatelly the open option works in this approach, don't sure what the difference is (file is probably still saved in temp folder and passed to the acrobat executable as a parameter).
Ulf brings up a good point - there's no benefit to embedding the PDF code in a JSF process, and I'm surprised it worked at all.
JSF isn't the type of system where JSF has to be in control all the time. If a given web page makes more sense as a plain old JSP or servlet, just do a plain JSP/servlet. You don't need to shoehorn it into JSF.
If this is the error we think it is, it won't show up in the server log, though, since the problem is on the client.