On Fri, 05 Oct 2001 15:32:10 "Shkuro, Yuri" wrote: > 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?
FOP did not support pluggable loggers properly. There needs to be some logging implementation and having our own, when there are others around, is not the best thing. The important things for logging are - handle threads - inversion of control > 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? As I have said before, yes it can be decoupled. This will require the user agent to be implemented and a few other areas to be improved. The best way to get this done is to help out. There are a large number of things that need to be done and it seems a large number of people who want them done. Helping out is a good way to get these things done. > 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]
