Karen Lease wrote:
> Configuration.put("baseDir", SOMEURLSTRING);

Thanks. I meanwhile figured it out that i could use

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
- 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.

J. Pietschmann

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to