On 17.06.2003 01:38:14 Victor Mote wrote: > I did a dry run of the startup refactoring (Session, Document, etc.) work > yesterday & this morning, and am satisfied that the concepts work. > Here are some comments: > > 1. I am going to start committing changes, hopefully this evening. Much of > the work is refactoring, but there are some substance changes as well, > specifically to allow multiple output options, multiple documents, etc. I > have therefore decided to implement it as a series of self-contained > changes, rather than dropping the entire change in at once. This will make a > better doc trail. Let me know if you object.
I'm a bit concerned that you call this "startup refactoring" where it's really API redesign in the end, I think. And that's an important topic where I would have expected you to ask for a "go for it" before starting on this. Generally, JustDoIt (tm) is a good thing but this is about the API and I'd like use to reach consensus on the direction. From the Wiki page I read that there are substantial differences in our (you, Jörg, me) ideas. I'm a bit unhappy that you placed/left Session in the apps package. I would like to see the apps package deprecated as a whole over time. I would like a cli package that only contains the stuff needed for the command line and I'd like to have (wish, not a demand) the main FOP api in the org.apache.fop package. And then I'm a bit unhappy about your terminology: Session, Document, RenderContext... Session and Document seem like "rubber terms" to me. Your Session looks very much like a FOProcessorFactory (analog to TransformerFactory). A session to me is a short-lived object used during one transaction. I think we should get consensus on the terminology first. Sorry if I'm a bit negative here. I certainly don't want to kill any enthusiasm. FOP needs this more than ever. > 2. Logging. During the dry run, I realized that I don't know whether we want > to have logging for a Session, or for each Document, or even at some finer > level of granularity. Session will be implemented as a singleton, so if we > only need logging at that level, then a static construct can be used to get > logging from /anywhere/ without adding anything. Otherwise, I'll add logic > that allows the Document object to either be directly accessed or computed > (by going up the object hierarchy) to get the logger. That seems more > desirable to me than implementing logging in all of the classes, but perhaps > I am missing something there. You're talking about a singleton. I hope you don't mean a GoF Singleton. A GoF Singleton in Java usually involves a static variable which I would like to avoid in our new API. Static logging ā la Commons-Logging is the easiest thing, sometimes even necessary if you ask people like Nicola Ken Barozzi. Even in Avalon-enabled software. The normal Avalon style of logging means a container is giving a logger instance to a service (see LogEnabled). As long as we're talking about services (Renderer, FOTreeBuilder, org.apache.excalibur.source.SourceResolver, org.apache.excalibur.xml.sax.SAXParser etc.), Avalon-style logging is superior (but more difficult to do right), because you can have multiple instances of the same service in a VM but logging to separate log files, for example, if you run two different applications in the same VM (in Avalon Phoenix, for example). You could have an invoicing system and a CRM system both running FOP for document production but logging to different log files. Ok, they could be separated by different classloaders but I still think not having statics in a server environment is better. Jeremias Maerki --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
