Monday, June 25, 2007

Images are not Visible in the BIRT WebViewer on Weblogic, Websphere

I came across a problem where the images in BIRT reports were not visible. Go through the Checklist below:

  • Are you using the BIRT Web Viewer to see the rendered BIRT reports?
  • Are you viewing rptdesign or rptdocuments?
  • The BIRT report is seen correctly when BIRT Web Viewer is deployed on Tomcat, JBoss, WebSphere 6.1 (i.e. images are visible). The temporary directory used to store images is present in the extracted WAR on these servers.
  • Whereas images for in the same report are not visible when the same BIRT WebViewer is deployed on WebLogic or WebSphere 5.1. The temporary directory used to store images is not present in the extracted WAR on these servers.
  • Log contains the message:
org.eclipse.birt.report.engine.api.HTMLServerImageHandler handleImage
SEVERE: imageURL or ImageDIR is not set!

GOOD NEWS: This is a known issue with the BIRT WebViewer 2.1.x. The BIRT bug id is 169873. It has been observed on WebLogic 9.1, 9.2 and WebSphere 5.1. The fix is already available in the latest BIRT build 2.2 RC3. The Final BIRT 2.2 release is expected by end of June 2007.

Check the details here:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=169873
http://dev.eclipse.org/newslists/news.eclipse.birt/msg15609.html

I had verified that installing BIRT Web-Viewer 2.2RC3 fixes the problem for WebLogic on Windows and Solaris. Some other people claim that it fixes for WebSphere as well. The images in rptdesign, rptdocument files are correctly visible in the browser. So the fix by BIRT team (for 169873) indeed solves the problem.

BAD NEWS: If you do not wish to upgrade to the BIRT WebViewer 2.2, I am afraid there is no easy fix which will solve your problem. People (including myself!!) have tried a number of tricks in vain. The only way out is probably to handle the temporary images by yourself, write a new Servlet to stream those images and change the report rendering code to have the images point to the new Servlet.

Images in MHT not visible: Issue 2

MHT Issue 2:

The images in MHT files are not displayed in IE. Instead a red cross appears.

Just check whether the URL to the MHT file contains any Spaces, encoded non US-ASCII, Special characters or for that matter any encoded characters. Well, well, well if it does then there is nothing much you can do about it! It is a known Microsoft bug. Microsoft has hot-fix for it. The hotfix description mentions only “Spaces” but the fix works for all encoded characters like spaces, internationalized characters, special characters, etc. The details are here:

Windows XP

SP2: http://support.microsoft.com/kb/891019

SP1: http://support.microsoft.com/kb/895394

Strangely, it is free but not available for direct download. Nor is it a part of any of the Microsoft Patches as there are no patches released since the problem was found! I hope to see it in Windows XP SP3 though. For now, you will have to call up support and they will happily give you the link to it. You will get it almost instantly. I know it is really funny to ask ones client to apply the hot-fix on all the machines. So you might want to consider some alternatives.

Alternative One:

Encode the part of the URL which has the problem causing characters. Personally, I would prefer HEX encoding. You can encode the MHT URL into HEX at the point it is generated. Pass it as a URL/request parameter henceforth. The code which streams out the MHT file will now have to decode it back from HEX and extract the information needed.

Let Me know if you find any other alternatives :P

Sunday, June 17, 2007

Images in MHT not visible: Issue 1

I've witnessed a couple of of problems related to the images in MHT (web-archive) files streamed from a J2EE web-application. If you are facing similar problems then read on to know why it happens and how can you fix them. Even though some of the solutions are discussed and illustrated Java, the same applies to other web technologies trying to serve MHT files. I will be considering only the most common browsers, Mozilla Firefox and MS Internet Explorer as I've not tried the fixes with other browsers.

I will post various problems and their solutions over the next few days.

MHT Issue 1:
The MHT file shows and open save dialog box.
OR
MHT file is rendered as and ASCII text file.
Make sure that your browser supports MHT. By default Microsoft Internet Explorer supports MHT files. If you are using Mozilla Firefox then you can install a plugin to render MHT files. As of now it isn't available for the latest version of Firefox. So you might have to consider switching an older version. But if you don't have the plugin installed then you will always get the Open/Save dialog in Firefox.

The problem could also be with the response sent by the server. The HTTP headers of the response sent from server should be set correctly. The content type should be set to "multipart/related". Content-disposition to "filename=yourfilename.mht". You should also add "charset=UTF-8" if your file contains any internationalized UTF-8 characrters. So set the complete Content-disposition to "filename=yourfilename.mht;charset=UTF-8". Make sure that the url used to access the file contains "yourfilename.mht" (or "xyz.mht" or "abc.mht"). It basically helps the browser understand that you are accessing a MHT file.
Sample URLS:
Direct URL
"http://localhost:8080/context/myfile.mht"
OR
In case of URL to a a servlet that streams the file you may add a dummy requst parameter like:
"http://localhost:8080/context/streamServlet?&dummyParm=foo.mht"

Note that the foo.mht is just a dummy parameter to help browser understand that you are accessing a MHT file. It need not be the actual name of file.

Once all of the above are done, the browser should be able identify that the file is of type MHT and it will then try to render it accordingly.