Hello, we are running on Weblogic 8.1 and using FOP for rendering report PDF's with images. It works fine, but sometimes (till now 2x) it happens that all threads in WLS are blocked at the same place - when rendering PDF and loading some image. Threads never get awaked, restart of WLS is needed. I attach piece of thread dump. All threads have the same stacktrace as seen bellow. Vasek Tregner "ExecuteThread: '19' for queue: 'weblogic.kernel.Default'" daemon prio=8 tid=000b1980 nid=52 lwp_id=1404872 waiting on condition [0x12a89000 ..0x12a884f0] at java.lang.Thread.sleep(Native Method) at org.apache.fop.image.GifImage.loadImage(Unknown Source) at org.apache.fop.image.AbstractFopImage.getBitmaps(Unknown Source) at org.apache.fop.pdf.PDFXObject.output(Unknown Source) at org.apache.fop.pdf.PDFDocument.output(Unknown Source) at org.apache.fop.render.pdf.PDFRenderer.render(Unknown Source) at org.apache.fop.apps.StreamRenderer.queuePage(Unknown Source) - locked <4f570c80> (a org.apache.fop.apps.StreamRenderer) at org.apache.fop.layout.AreaTree.addPage(Unknown Source) at org.apache.fop.fo.pagination.PageSequence.format(Unknown Source) at org.apache.fop.apps.StreamRenderer.render(Unknown Source) at org.apache.fop.fo.FOTreeBuilder.endElement(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.fop.apps.Driver.render(Unknown Source) - locked <4f570fd8> (a org.apache.fop.apps.Driver) at org.apache.fop.apps.Driver.run(Unknown Source) - locked <4f570fd8> (a org.apache.fop.apps.Driver) at cz.csas.cicnet.tapestry.services.PdfService.service(PdfService.java:75)
Sorry, but we won't look into this bug. Since the code of GifImage didn't change much I'd assume it would resurface in your particular environment even if you upgraded to FOP 0.93. We're likely to soon drop support for JDK 1.3 which removes the necessity to keep GifImage around in the first place, as image loading for GIF will be done through ImageIO. BTW, it would have been interesting to know the maker and version of the JVM you're using. Anyway, I've got a possible work-around (no guarantees) for you if you absolutely have to stay with FOP 0.20.4 which is by now 4 years old: Make JAI available to FOP and change org/apache/fop/image/FopImageFactory by changing the following code section: if ("image/gif".equals(imgMimeType)) { imgClassName = "org.apache.fop.image.GifImage"; // imgClassName = "org.apache.fop.image.JAIImage"; Comment the line with "GifImage" and uncomment the line below. Recompile FOP from the sources and FOP will attempt to load GIF images through JAI. Upgrading to FOP 0.20.5 won't help in this case as the code is pretty much the same. You could also try to use a different JVM in your environment as I don't think this is just a FOP bug. After all, a lot of people used GIF images with FOP 0.20.4 and 0.20.5 and it worked for them. If you can upgrade to FOP 0.93 that particular problem would go away anyway but you have to do a migration which may be more work for you. Good luck!
batch transition to closed remaining pre-FOP1.0 resolved bugs