RE: FOP in WebSphere and some general notes (Was: Re: Using FOP i n Servlet)

["Savino, Matt C" <Ma...@questdiagnostics.com>]

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:Yuri.Shkuro@gs.com]
> Sent: Friday, October 05, 2001 6:32 AM
> To: 'fop-dev@xml.apache.org'
> 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: joerg.pietschmann@zkb.ch [mailto:joerg.pietschmann@zkb.ch]
> Sent: Friday, October 05, 2001 8:49 AM
> To: fop-dev@xml.apache.org
> 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: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org