I totally agree with the suggestion to get rid of as much extra libraries as possible. Our infrastructore guys were very perplexed when I told them that I am going to use FOP in my project, and, by the way, I need those five extra jars in the app server class path. I don't know how much avalon framework is integrated into FOP, but with respect to logkit - logging is a simple API, and since FOP already supports pluggable loggers, why not indeed make those loggers API driven, instead of logkit dependent?
I was able to use FOP without including jimi.jar, but batik is required even though I don't use SVG. Why is that? Can't it be decoupled somehow and only loaded when SVG is used? YS -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, October 05, 2001 8:49 AM To: [EMAIL PROTECTED] Subject: FOP in WebSphere and some general notes (Was: Re: Using FOP in Servlet) Karen Lease wrote: > Configuration.put("baseDir", SOMEURLSTRING); Thanks. I meanwhile figured it out that i could use SOMEURLSTRING="file:"+xslFileName Some other notes on FOP 0.20.2 in general and using in in an IBM WebSphere Server in particular (including problems actually caused by Batik): - IBM has their own Logging mechanism (though it's primitive). Using LogKit is of no real use for me, it just forces me to put logkit.jar in the classpath which noticable increases startup time (invconvenient in development only, but i *am* developing...). Could you use an lightweight interface which belongs to a FOP package, and an default implementation which dispates to an LogKit logger? Something like the ErrorListener class in JAXP. I could then provide my own implementation to the interface without having to pull in the whole LogKit. This would also make for an much better separation of the libraries, there would be just one class in FOP which uses LogKit stuff in the delegation and setup routines. - Something similar goes for the avalon framework. I thought i could avoid putting the jar in the classpath by not using the Driver class, but it still goes in by a remarkably twisted way: somewhere during SVG rendering in Batik a batik.bridge.BridgeContext is created, which quite unnecessarily creates a (Batik) DocumentLoader (there is no document because FOP gets the XML already as SAX event stream), which in turn gets a XML Parser name from the SVGUserAgent supplied by FOP which gets it from the fop.apps.Driver class. While the primary fault is in Batik which should create stuff more lazily (you may forward this complaint!), i don't think the fop.apps.Driver should act both as central repository for configuration settings and be an Avalon loggable at the same time. In fact i'd like to have an interface to FOP which resembles slightly more the XSLT TransformerFactory/ Transformer interfaces, with setting parameters using a Parameters object like Java Mail mixed in. The framework stuff including setting up a LogKit logger and and all that could be build around that. If this catches your curiosity, ask me to write up a more complete specification. - There is a unfortunate problem with Batik and the IBM class loaders. In Websphere, there is an "ApplicationServer", a JVM running in its own OS process, which can contain several "WebApps". Each WebApp may have its own classpath settings. At first i added batik.jar (and all other jars) to the WebApp specific classpath. Several Batik classes have static class variables which register some stuff in the AWT run time at class load time. If there is more than one WebAbb using Batik, directly or indirectly, the first WebApp has no problems, but the WebApp coming second gets errors roughly like "instance <NNN> of <class name> exists". I got around this by adding the jars to the ApplicationServer classpath, where they really belong (but this is awkward without permission to mangle the server startup files). Some minor points: - In fop.apps.Driver, the _areaTree variable and related imports and statements appear to be defunct and can probably be deleted. - FOP gets a null pointer exception if there is no default namespace and an element without a namespace prefix slipped into the input. This is because in fop/fo/FOTreeBuilder.java Line 218: HashMap table = (HashMap)fobjTable.get(uri); fobjMaker = (FObj.Maker)table.get(localName); table is null. I believe this also happens always if the namespace URI is not recognized. - The PixelToMM factor (0.35277...) is repeated remarkably often in the source. Regards J. Pietschmann --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]