I agree about removing the libraries. I'm running large, simple reports on Weblogic (see my benchmarking post from a few days ago for details). Some sort of stripped down, built-for-speed, no-SVG, no-logging FOP that only uses the FOP, Xalan, and Xerces jars would be ideal for me.
I'd be willing to help work on such a verison for us corporate production WebApp guys. Any other interest? -Matt Savino > -----Original Message----- > From: Shkuro, Yuri [mailto:[EMAIL PROTECTED]] > Sent: Friday, October 05, 2001 6:32 AM > To: '[EMAIL PROTECTED]' > Subject: RE: FOP in WebSphere and some general notes (Was: > Re: Using FOP > in Servlet) > > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]