[Installation, Configuration & DEPLOYMENT] - Re: cannot open excel files (with excel in IE) which stored
by zlatan24
By all means in this situation the best way will be-http://www.recoverytoolbox.com/unable_to_read_xls_xlsx.html,because tool has many facilities and is free as far as I know,utility solve problem with corrupted files in Microsoft Excel format and repair Excel-unable to read file,also next problems: Microsoft Excel unable to read file, Excel the file may be read-only or you may be trying to access a read-only location, or excel cannot access read-only document, the results of your work may be lost,will help you, when cannot read Excel file because corrupted and when Excel 2007 unable to read file xlsx,can analyze a corrupted file and preview the results,export to Excel unable to read file these results to a new Microsoft Excel worksheet,yet export to Excel file after exporting it shows unable to read file, unable to read file can t save on Excel and Excel the file may be read-only or you may be trying to access a read-only location.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236742#4236742
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236742
16 years, 10 months
[Remoting] - HTTPUnMarshaller and InvocationResponse objects
by tfennelly
Hi there.
We encountered something that appears to be a bug when using JBR client to a JBR Server (http).
In the above scenario, the JBR server returns an InvocationResponse to the JBR client (if the user-agent starts with "JBossRemoting"). Everything works fine if we don't set a Content-Type header in the response metadata (or we set it to a binary type). If it's set to a non-binary type however (e.g. text/xml), we get an error on the client side because the HTTPUnMarshaller only decodes the response stream as an InvocationResponse for non binary content types.
Could be wrong (of course), but the mechanism seems flawed. If the HTTPMarshaller is going to wrap the response object payload in an InvocationResponse, then is it not effectively changing the content type? In this situation, should it not be reseting the content type to octet-stream (or whatever) and storing the wrapped payload type (e.g. "text/xml") on the InvocationResponse. Then on the client side, the HTTPUnMarshaller will decode the InvocationResponse properly and can reverse the Content-Type on the response metadata it receives before returning the wrapped payload etc etc
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236737#4236737
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236737
16 years, 10 months