Sorry if I'm not replying inline, but with some mails Outlook Express seems
to be unable to properly add >>> s . :-(     (If anyone knows a workaround,
please let me know)

Anyway, your description is correct, and very well done.
One of the main points in avalon is the IoC (inversion of control), where
the Container pushes things to the Components.

Static accessors are bad in this regard, as they make the Component ask
something to a class that is not even a container. This usually brings to
the problems FOP has had with config until now.

In a server environment especially, good role hierarchy and containment is
paramount, and Avalon helps to enforce and use it.

One thing though: Logging is a bit different than other things... it's not
really a component, but an aspect.
This means that we would need another programming language to use it
correctly from a framework POV...

In practice, I have seen that the best thing is making the big blocks get a
Logger from the parent, and have the smaller classes get it from a static
method that permits the usage of a "key", that in the case of important
classes can be set from the outside.

As for helping, I will be happy to do so.
Unfortunately I have not had time till now to give an active hand, but now I
can find some time.

The good news is that Forrest is running (
and that we are starting to convert the xml.apache projects to use the new
Since you have showed interest, FOP will be one of the first projects to
have the site automatically published by Forrest :-)

Nicola Ken Barozzi                   [EMAIL PROTECTED]
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)

----- Original Message -----
From: "Jeremias Maerki" <[EMAIL PROTECTED]>
Sent: Wednesday, May 29, 2002 5:18 PM
Subject: Re: [REDESIGN] configuration

> Here are some ideas about how we could do the configuration for FOP.
> Comments are welcome.
> Use this class and various supporting classs (already in avalon
> framework jar):
> org.apache.avalon.framework.configuration.Configuration
> From a brief look at how this works it should be quite easy to use. We
> just need to decide on an appropriate xml structure. I have attached an
> example.

It is. I'm using this stuff every day.

> This can be used either with an xml file on the command line or through
> embedding, eg. cocoon could pass a fop configuration class.
> If the classes are not configured then default values are used.
> Configurable classes:

I'd like to elaborate because I'm not sure that everyone is familiar
with Avalon's concepts: These classes will implement the "Configurable"
interface from Avalon. Following the concept of IoC (those who are not
familiar with this term, please look up Avalon docs) the configuration
is set by the container (ex. Cocoon or our command-line wrapper) on the
child (Driver, Renderer etc.).

> - Driver
> Passes configuration to user agent if not already set and to renderers.

Right. Driver will probably still remain our top-level component,
serving as a black-box of the whole FOP-process.

> - All renderers (ie. Renderer, StructureHandler implements)
> This is so that the renderer can get its own specific information.
> The PDFRenderer could have font setup, stream filters etc.

Correct. That's something I'm burning to do for a long time. PSRenderer
will get very configurable eventually.

> - Configurable FOUserAgent (have default FOUserAgent that can be
> used/extended without config)
> To make it possible to setup all the various options like dpi.

I'm still at a lack of knowledge on these new things. :-( But it sounds
reasonable. I think a lot of thinking when using Avalon goes into which
classes are components (they get a logger, configuration etc. and
provide some sort of service) and which are merely data-holding classes
like an InlineArea. Correct me if I'm wrong: UserAgents are those
classes that do the heavy work that was formerly distributed in many
different classes directly on classes that change into simple
data-holding classes at the moment.

> ----------
> The logkit Logger can be configured using this but it is not
> appropriate. If FOP is run from the command line then it should do what
> it already does and when embedding it would setup its own logger.

Logging is also something that is set on the child by its container. The
command-line wrapper sets a simple ConsoleLogger on the Driver by using
the LogEnabled interface.

Other containers like Cocoon will configure their Logging somewhere else
and set the desired Logger using LogEnabled on Driver, which in turn
passes some child logger of the given one to its children.

> The image cache and other cache are similar. These can be set with a
> static method and through the driver respectively.

I'd like to avoid the static stuff, if possible. There's the concept of
a ComponentManager (or after an evoluntionary step the ServiceManager),
which allows components to look up services provided by the
container/parent. There are multiple implementations in Avalon:
ExcaliburComponentManager (ECM), Fortress, Merlin, Phoenix. Using this
mechanism forces us to think again about some interfaces, or helps us to
easily provide multiple implementations of the same interface.

I can only say this: restructuring FOP to use this concept means some
work. We've done it for our applications and we love the result. I'm
sure Nicola Ken Barozzi can help here. I can help, too, I want to. I
just can't invest so much time as would be necessary at the moment. I'll
have 5 weeks off in August from which I intend to invest at least a week
into FOP. What I propose here is just my personal opinion and I can
understand if you, Keiron, don't want to be braked by having to dive too
much into Avalon. But I'm trying to help as much as possible. I'm
drowning in work but try heavily to get out of this.

There's not only cache components (for which Avalon Excalibur may
provide some helpful stuff), but also things such as an URI/URL-Resolver
(adopted by Excalibur from Cocoon) which may be an interesting feature
and may improve the integration with Cocoon. Actually, using Avalon
helps integration with Cocoon in a general sense. I'm also thinking
about creating a font facility which can manage fonts across renderers.
There may also be little components like a table column builder for
which different implementations are thinkable. We've had two different
approaches on line-breaking, right? I'm sure there are others.

I think, looking at Cocoon is inspiring. How they cleanly split up the
system into highly configurable and exchangeable parts. And it helps
killing those multi-threading problems (I hope).

There has been some discussions about configuration. There's always the
distinction between system configuration or component setup on one side
and calling parameters (ex. from the command line or from calling a
method on Driver) on the other. I've seen the latter having been handled
through Avalon's Context interface. Maybe this is not even necessary. I
think this may have to be investigated further. We can always ask the
Avalon guys who are eager to help when someone (especially an Apache
project) wants to adopt their patterns. I can be contact person. I'm
working with Avalon for about 9 months, but I'm not a specialist, yet.
Maybe Nicola Ken Barozzi also wants help out a bit. I think he offered
his help at one point.

So much from me at the moment. I hope I contributed some constructive
words and that you guys understand what I'm trying to tell. I know that
I'm not a pro in this regard.

Jeremias Märki


Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
Tel. +41 41 317 2020 - Fax +41 41 317 2029

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to