Jeremias Maerki wrote: > 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 certainly thought I had tacit consent. > 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. My humble apologies. What is the easiest way to roll it back? Is there an automated way? > 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. OK. In my terminology, Session is a long-lived object that lives, well, for the Session. Document are children of Session. The only part of Session that you have seen is a renaming of Driver to Session. That is all that has been committed so far. But eventually nearly all of existing Driver gets pushed down to Document, RenderContext, and RenderTask. The only thing that really still lives in Session is the logging stuff, and it might belong with Document (under my scheme). > 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. Yes, I am talking about GoF Singleton. I understand the reluctance to use static variables, but I haven't adopted the no-tolerance approach that you have. The alternative is to either carry the static information around with you in every method that might need it, or to actually store the information in every object that might need it. I already see that with the logging. If it is needed, then OK, but I don't see it yet. > 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. That sounds possibly useful for what we are doing. Victor Mote --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
