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)

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

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.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]

Reply via email to