You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Glen Mazza <gr...@yahoo.com> on 2004/03/24 03:11:16 UTC
[VOTE] Switch from Avalon to Commons-Logging
Team,
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?
Thanks,
Glen
[1]
http://marc.theaimsgroup.com/?t=108004833700001&r=1&w=2
[2]
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108005125410855&w=2
[3]
http://marc.theaimsgroup.com/?l=fop-dev&m=105181262130439&w=2
[at the bottom]
[4] http://jakarta.apache.org/commons/logging/
[5]
http://marc.theaimsgroup.com/?l=struts-user&m=102090805604782&w=2
[6]
http://lsd.student.utwente.nl/gump/jakarta-commons/commons-logging.html
Re: [VOTE] Switch from Avalon to Commons-Logging
Posted by Christian Geisert <ch...@isu-gmbh.de>.
Glen Mazza wrote:
> Team,
>
> 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.
[..]
> Thoughts? Votes?
So the vote is actually if we should use Avalon at all and not just
about logging. If we drop Avalon (my knowledge about it is quite
limited so others (Jeremias/Joerg) will hopefully comment on it) then
commons-logging makes sense.
--
Christian
Re: [VOTE] Switch from Avalon to Commons-Logging
Posted by Chris Bowditch <bo...@hotmail.com>.
Glen Mazza wrote:
<snip/>
> 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.
Im not going to vote straight away, ill wait for some of the other
committers to speak up. I do agree with your thought process.
>
> 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.
Yes I agree.
>
> 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.
Yes another very good point.
>
> 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?
In the last couple of years there has been a lot of discussion on this
list about avalon and getting FOP to work with parts of avalon other
than just logging. As far as I am aware FOP still uses avalon only for
logging. But a lot of more experienced committers have often spoke in
the past of using other features of avalon to FOP's great advantage.
What those features are or advantages are I dont know. Hence, ill wait
to hear from others before casting a vote. You could always check the
archives to get an idea.
Chris
Re: [VOTE] Switch from Avalon to Commons-Logging
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Glen Mazza wrote:
> Thoughts? Votes?
-0 (not a veto)
J.Pietschmann
Re: [VOTE] Switch from Avalon to Commons-Logging
Posted by Jeremias Maerki <de...@greenmail.ch>.
I'm not sticking to Avalon. All I can say is that I've successfully used
Avalon to build a flexible server for document processing using the ECM
container (same that Cocoon is currently using). I loved to work with it,
especially after I was able to rewire the whole application at a
customer's site by only changing the XML configuration files. I didn't
have to change one line of Java to adapt the application to the
unsupected requirements found there.
I'm open to investigate other possibilities, even to simply try to work
without any outside help. What I find important is to have a way to
configure FOP using XML in a flexible manner, to have something that
helps us split up FOP into the right set of components, to have
exchangable components, to have FOP easily integrate with other packages
such as Cocoon.
I'm still thinking that we can do without a sophisticated container such
as Merlin, even ECM. The basic Avalon patterns established my Avalon
Framework already provide an interesting environment. I'm sure that even
Stefano and Pier would agree to that. They simply see different
requirements specifically targeted at Cocoon. FOP is surely something
different. But if we find something better, I will fully support it.
Well, let's have an eye on what's going on in Cocoon-land, but let's
also not blindly follow what they're doing.
On 28.03.2004 18:07:15 Glen Mazza wrote:
> Jeremias, I reached your conclusion yesterday in doing the logging
> conversion (I'm only 2/3rds there right now): namely, to keep Avalon
> for the time being for the non-logging components, but just to replace
> its logging component with Commons-Logging. It was just in doing the
> conversion yesterday that I first noticed that we were using Avalon for
> other things (even after switching to C-L, it will still be in about
> 10-15 classes over a few packages), namely the configuration that you
> mention. I also agree in not switching away from the Avalon
> configuration unless there is something better in Commons--*** or
> something better we can do ourselves. I haven't studied configuration
> (hence am not very knowledgeable about it), and it is not among my
> priorities--other team members have thankfully been taking the lead on
> configuration.
>
> Also, if there's another feature you like from Avalon, we can always use
> it. To me, Avalon is now just another library, like the Commons--***
> libraries. It's just that FOP won't be living and breathing Avalon 24/7
> anymore--we'll use certain parts of it where it's better than
> Commons--*** libraries, but not just blindly using it "because it's
> Avalon". The entire 30-40 email Cocoon thread on "building on stone"
> was not much of a confidence builder in adopting the latter
> philosophy--email after email, the team had little good to say about
> Avalon as an application framework, and is now considering painful
> contortions [1] to liberate themselves from it.
>
> Thanks,
> Glen
>
> [1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108016162526312&w=2
>
Jeremias Maerki
Re: [VOTE] Switch from Avalon to Commons-Logging
Posted by Glen Mazza <gr...@yahoo.com>.
Jeremias Maerki wrote:
>-0 (I don't feel I'm in a position to veto) for now as long as you're
>only talking about the logging aspect. FOP needs a few things more, as
>does Cocoon. Simply dropping Avalon doesn't help. If you look at
>http://nagoya.apache.org/wiki/apachewiki.cgi?FOPAvalonization you can
>see that logging is only one item in the requirements list we put
>together.
>
>
>
Jeremias, I reached your conclusion yesterday in doing the logging
conversion (I'm only 2/3rds there right now): namely, to keep Avalon
for the time being for the non-logging components, but just to replace
its logging component with Commons-Logging. It was just in doing the
conversion yesterday that I first noticed that we were using Avalon for
other things (even after switching to C-L, it will still be in about
10-15 classes over a few packages), namely the configuration that you
mention. I also agree in not switching away from the Avalon
configuration unless there is something better in Commons--*** or
something better we can do ourselves. I haven't studied configuration
(hence am not very knowledgeable about it), and it is not among my
priorities--other team members have thankfully been taking the lead on
configuration.
Also, if there's another feature you like from Avalon, we can always use
it. To me, Avalon is now just another library, like the Commons--***
libraries. It's just that FOP won't be living and breathing Avalon 24/7
anymore--we'll use certain parts of it where it's better than
Commons--*** libraries, but not just blindly using it "because it's
Avalon". The entire 30-40 email Cocoon thread on "building on stone"
was not much of a confidence builder in adopting the latter
philosophy--email after email, the team had little good to say about
Avalon as an application framework, and is now considering painful
contortions [1] to liberate themselves from it.
Thanks,
Glen
[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108016162526312&w=2
Re: [VOTE] Switch from Avalon to Commons-Logging
Posted by Jeremias Maerki <de...@greenmail.ch>.
(Sorry for the delay, I've been on "green" holidays again).
On 24.03.2004 03:11:16 Glen Mazza wrote:
> Team,
>
> 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]).
It's correct that Avalon has a big problem. I have recently caught
myself looking at alternatives though I haven't made up my mind, yet.
> Cocoon is higher-level than
> FOP [3], so I think what's true for them is doubly
> true for us.
However, the reasoning applied to Cocoon doesn't necessarily apply to
FOP. The parts of Avalon we're currently using are rock-solid. Always
were. I've simply never managed to really sit down and do the work to
profit from the higher level services (in Excalibur) and start using a
container.
It seems that I would now have to start yet another crusade to explain
why Avalon (or a similar technology) would help in the design of FOP. I
simply don't have the time for it and can only send you to the fop-dev
archives.
> 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.
As was already hinted Avalon is not only about logging. We're currently
using the logging aspect of Avalon and in HEAD I've used Configuration
objects to configure some of FOP's components. Dropping Avalon means the
Configuration parts no longer work.
> 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.
-0 (I don't feel I'm in a position to veto) for now as long as you're
only talking about the logging aspect. FOP needs a few things more, as
does Cocoon. Simply dropping Avalon doesn't help. If you look at
http://nagoya.apache.org/wiki/apachewiki.cgi?FOPAvalonization you can
see that logging is only one item in the requirements list we put
together.
However, I'm in favor to introduce Commons Logging, at least for certain
components in FOP. The PDF library, for example, is a very good example
where Avalon-style logging doesn't work very well. Using a static logger
there is much more convenient. I had discussions a couple of years back
with Nicola Ken Barozzi about the differences between instance-oriented
logging (Avalon-style, see below) and static logging (JDK14, Commons
Logging, Log4J). Not everything can cleanly be done with Avalon-style
logging but it has its advantages.
I realize that this means introducing another JAR to the classpath
without the (immediate) possibility to get rid of Avalon. But without a
reasonable alternative to handle the aspects other than logging I'm
against removing Avalon right now.
> 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.
Correct, but that's not all there is to it. Let me explain:
In Avalon-Style logging, you have a Logger interface which is
practically the same as all the other Logger interfaces.
But what's different in Avalon is the LogEnabled interface that is
defines in Avalon Framework. A component implements this interface and
gets a Logger instance of the enableLogging(Logger) methods right after
instantiation. This is IoC (Inversion of Control, see Avalon
documentation for more info) in contrast to static logging where the
component actively fetches a logger.
One advantage is that you can easily have different logger instances for
the same component, for example, if you want to give FOP a different
logger for each processing run. I needed that back when I was still
using FOP at work. If you just log into a big file in an MT environment
you can't find out in a reasonable timeframe which document caused which
problem. Logging the thread IDs helps but the output gets totally mixed
up.
Avalon logging is great and powerful when you're logging from services
but it's a PITA when you have code in complex data structures (such as
the FO tree) where you would need an instance for the logger for every
object instance.
> 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.
Yep. Especially since I'm not ready, yet, to fully accept JDK 1.4
logging.
> 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.
Same is true for integration with Cocoon which is Avalon-based. Cocoon's
logger can simply be passed to FOP. (And we don't know, yet, how Cocoon
will look like later. For now it's Avalon-based.)
> 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.
Before Avalon is removed I request a plan be made on how to handle the
configuration aspects in FOP. Avalon provides a very good infrastructure
to handle this. I've even used it in my Barcode4J project (which is a
lot smaller than FOP) because it makes configuring a component using XML
a no-brainer. I must say, however, that the Avalon-integration will
probably become optional (implemented in special subclasses) as
Barcode4J is reasonably simple to work with Bean-style configuration.
But still I have absolutely no plans the remove this small dependecy to
Avalon Framework.
Has anybody here already taken a look at Hivemind (found in Jakarta
Commons)?
Jeremias Maerki