We Keep Coding

ms word file download issue in servlet from unix server to windows

While uploading doc file(example test.doc) to server(unix machine), I am using apache commons jar which gives me FormFile instance at server side which is having all the data in byte array form.
When I write the same byte array to response output stream and send it to browser to download the same file, weird content is shown. I get one pop up to select encoding in which i would like to see the data and weird data is shown in that doc.The content type is set as follows :
response.setContentType("application/msword");
response.setHeader("Content-Disposition", "attachment;filename=test.doc");
I think that while writing data to output stream, meta data related to doc file is also written which causes this issue.
Is there anything specific for doc or docx file formats, which needs to be done so file is in proper format and i can see correct data which i uploaded or I am missing something?
Any help would be appreciated.
Thanks in Advance.
Let me know if more info is required.

There's a known issue in Microsoft which provide workaround for the
Encoding Pop Up

It may not be a fix for your problem because I have not run any test around. But to check the correct mime types please refer to this link:
https://technet.microsoft.com/en-us/library/ee309278(office.12).aspx
Updated:
You can use response type as ArrayBuffer and set the content as Blob.
Blob([response], {type: 'application/vnd.openxmlformats-officedocument.wordprocessingml.document'});
Or this could work
response.setContentType("application/x-msdownload");
response.setHeader("Content-disposition", "attachment; filename="+ fileName);

Issues writing text file to IFS though jt400

All I'm trying to do is to drop a log on IFS
Here is my code:
def write(target_filename, data)
stream = com.ibm.as400.access.IFSFileOutputStream.new(AS400.sys, target_filename)
stream.write(data.to_java_bytes)
stream.flush
stream.close
end
When i read it though the jt400 library, it comes out ok.
But when i go thought the qShell or wrklnk the file seems empty.
Any ideas why? Is it the CCID?

Found the issue. I was using IFSFileOutputStream to write binary stream of text. By switching it to IFSTextFileOutputStream, problem was resolved.

Trying to force download of xml file fails in larger files

EDIT
I solved the issue itself by zipping the XML up and sending it out as application/zip. Still, the question remains why it does not work in plain XML.
I'm currently trying to let users of our website download an xml-file with so called "late responses", in case the automatic processing fails and their requests need to be looked at by a person. The site is basically just a simple GUI over a soap-webservice for the non-technical-inclined, but thats not that important for the issue.
When there are late responses, the site shows the total number and offers to download them, I'm currently archieving this via
// XML-content is aggregated and written to response outputstream
response.setCharacterEncoding("UTF-8");
response.setContentType(MediaType.APPLICATION_XML_VALUE);
response.setHeader("Content-Disposition", "attachment; filename=" + "ergebnisprot_" + new DateTime().toString("ddMMyyyyHHmmSS") + ".xml");
response.flushBuffer();
This works well if only about one to five responses are aggregated. The browser gets a download-popup and everything goes the way it is supposed to go.
But with larger files, depending on the individual size, but usually from about 10 responses upward, this popup does not appear. Instead, the browser renders the xml itself, which is undesirable, since it's considered of no use to the user to not have the file on his harddrive, or to have to then copy it himself into a file.
Does anyone know why this behaviour happens? Did I miss something in my header configuration?

Java mail PDF attachment not working

I am generating a PDF and trying to attach it to a mail as well as download it from browser using java. Download from browser works fine, but attaching to mail is where I am facing an issue. The file is attached. Attachment name and size of the file are intact. The problem is when I open the PDF from mail attachment, it shows nothing. correct number of pages with no content. When I attach the file downloaded from browser by hardcoding, it works fine. So I suppose the problem is not with the PDF generation. I tried opening both(one downloaded from browser and the other downloaded from mail) the files using comparing tool beyond compare. The one downloaded from mail shows conversion error. When I open with notepad++, both show different encoding. I not very familiar with these encoding thing. I suppose it is something to do with encoding.
I also observed that the content in mail download is same as the one at PDF generation. But the one at browser download is different.
An excerpt of what I get on browser download is as below(The content is too large to paste)
%PDF-1.4
%âãÏÓ
4 0 obj <</Type/XObject/ColorSpace/DeviceRGB/Subtype/Image/BitsPerComponent 8/Width 193/Length 11222/Height 58/Filter/DCTDecode>>stream
ÿØÿà
An excerpt of what I get on mail download is as below
%PDF-1.4
%????
4 0 obj <</Type/XObject/ColorSpace/DeviceRGB/Subtype/Image/BitsPerComponent 8/Width 193/Length 11222/Height 58/Filter/DCTDecode>>stream
????
I am using Spring MimeMessageHelper to send the message. I am using the below method to add attachment
MimeMessageHelper.addAttachment(fileName, new ByteArrayResource(attachmentContent.getBytes()), "application/pdf");
I've also tried another way of attaching but in vain
DataSource dataSource = new ByteArrayDataSource(bytes, "application/pdf");
MimeBodyPart pdfBodyPart = new MimeBodyPart();
pdfBodyPart.addHeader("Content-Type", "application/pdf;charset=UTF-8");
pdfBodyPart.addHeader("Content-disposition", "attachment; filename="+fileName);
pdfBodyPart.setDataHandler(new DataHandler(dataSource));
pdfBodyPart.setFileName(fileName);
mimeMessageHelper.getMimeMultipart().addBodyPart(pdfBodyPart);
Any help would be greatly appreciated. Thanks in advance

I'm not sure if this has anything to do with it but I noticed you're not setting the actual charset in pdfBodyPart.addHeader("Content-Type", "application/pdf;charset");, nor are you calling attachmentContent.getBytes() with a charset as parameter. How is it supposed to know which one you want to use?

What Content-Transfer-Encoding is being used for the attachment in the message you receive? Normally JavaMail will choose an appropriate value, but if document contains an unusual mix of plain text and binary, as your document seems to, JavaMail may not choose the best encoding. You can try adding pdfBodyPart.setHeader("Content-Transfer-Encoding", "base64");

I found out why it was'nt working. It is an encoding issue but nothing to do with MimeMessageHelper. The problem was I generated the PDF to an OutputStream and converted it to String and then converted it into byte array. When I converted to it to String the encoding changed resulting in the issue. So i fixed it by getting byte array from outputStream :)

How to change endianness when unmarshalling a CDR stream containing valuetype objects in Java

I've got marshaled CDR data all by itself in the form of a file (i.e., not packed in a GIOP message) which I need to unmarshal and display on the screen. I get to know what type the data is and have working code to do this successfully by the following:
ValueFactory myFactory = (ValueFactory)myConstructor.newInstance( objParam );
StreamableValue myObject = myFactory.init();
myObject._read( myCDRInputStream );
where init() calls the constructor of myObjectImpl(). and _read is the org.omg.CORBA.portable.Streamable _read(InputStream) method.
This works as long as the marshaled data is of the same endianness as the computer running my reader program, but I will need to be able to handle cases where the endianness of the data is different than the endianness of the computer running the reader. I know that endianness is in GIOP messages, which I don't have. Assuming I figure out that I need to change the endianness, how can I tell this to the stream reader?
Thanks!

If you access to the underlying ByteBuffer of your input stream, and then you can set the endianness. For example I use this to open matlab files myself
File file = new File("swiss_roll_data.matlab5");
FileChannel channel = new FileInputStream(file).getChannel();
ByteBuffer scan = channel.map(MapMode.READ_ONLY,0,channel.size());
scan.order(ByteOrder.BIG_ENDIAN);
However, I dont know if you corba framework is happy to read from a bytebuffer (corba is so 90ies). So maybe that does not work for you.