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]
