The Cocoon project is starting to move away from
Avalon.  Their "building on stone" email thread today
[1], deals with the need to build Cocoon on a solid
framework they have control over, and not on the
framework of another team that is apparently suffering
from high turnover [2]).  Cocoon is higher-level than
FOP [3], so I think what's true for them is doubly
true for us.

Accordingly, I think it's time now for us to do the
same for FOP.  I'd like us to drop the Avalon library
for 1.0, and switch to Jakarta Commons-Logging [4] as
a replacement for Avalon's logging component.  For
1.0, I propose having FOP join Batik, Xalan, Xerces,
AntennaHouse, RenderX, Struts, Axis, and (upcoming)
Cocoon in no longer shipping with Avalon, nor
requiring its users to import that library into their
applications in order to use FOP.  Here's my +1.

Commons-logging offers the same type of logger options
[5] that Avalon logging does:  The user has a choice
of no logger, stderr logger, Log4J, and JDK 1.4
logging.  They can also create additional logging
types.  Commons-logging is currently being used by
major open-source applications such as Tomcat,
Tapestry, Apache Axis and Jakarta Struts, and *many*
others [6], so we'll be moving into very good company.

Another huge advantage I see for FOP in particular is
exceptional integration with Struts applications.  For
Struts developers, the same commons-logging instance
that they presently use for their application coding
can be passed into FOP during PDF generation.  No more
needing to create a separate Avalon logging instance
in their code, or (possibly) needing to have two
different output logging files, one for each logging
instance.  This will look very nice architecturally
for both FOP and Struts.

I'll be more than happy to take care of the conversion
for us--I'll make the change via a patch for us to
review before committing.

Thoughts? Votes?



[at the bottom] 

Reply via email to