Peter B. West wrote: > Regarding configuration in FOP, it is interesting to note that there are > two different config hierarchies depending on whether the environment is > uniform, as, e.g., in a single thread, or diverse, as in the example > Arnd offered. (That is, a separate process constructs stylesheet > information and other variables into an instance-specific storage > location, and invokes a fop thread with a reference to that location.) > > In the first case, the config hierarchy is: > > system config > user config > command line
This is an application centric view. And these are the traditional contexts used in many other application in order to avoid repeated setting of almost static stuff while still allowing flexibility. We are dealing with other points of view: - FOP used embedded in some other software consuming and producing byte streams - FOP as part of other software performing its own drawing and user interaction - FOP as a self contained application You config hierarchy applies only to the last. The first application of FOP should only make minimal assupmtions about available infrastructure and other environmental issues. In particular, it should not assume there are even config files or command line parameters directly regarding FOP to read. There is no use to distinguish between various config files and command line parameters. The mechanisms used should be universally available, like Java properties for very static stuff and fallback values and interfaces for supplying user font data, for which there could be a default implementation which reads the data from URLs, which by default are resolved to certain file URLs. Around this core could be a shell which provides for FOP specific config files and command line parameter filtering, much like the XWindows libraries provide similar stuff. This can be used both for embedding FOP elsewhere as well as for a stand alone FOP application. For the core, I'm still thinking the factory pattern used by JAXP is sensible: the factory is a singleton which serves as a template for the FO processors. All default configuration values are kept there, they are initialized with fallback values hard coded or read from java properties when the factory is created and can be changed at any time. After a processor is created, the settings for this processor can still be changed until the formatting run starts. After the run ends, the processor object is discarded (no reset) and new processors are obtained from the factory. There are no MT issues because all methods on the factory and the processor object are synchronized at their respective objects, and the objects hold all necessary data. This model suits the servlet environment particularly well. It could be claimed that some stuff from a processor run could be reused and should be cached, for example the FO tree. But I think you can as well cache the produced byte stream. It's another matter in case of the AWT renderer, there could be possibly many rerenderings form the same area tree (console refreshs, scrolling etc). But then, the AWT rendering processor is no necessarily discarded after each display refresh. Regards J.Pietschmann --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
