On Nov 14, 2007, at 13:24, Michael Tracey Zellmann wrote:
Hi
Sorry for the late reply...
Thanks for the response.
I am trying to think of a way to still succeed.
What I want to do is to send all logging messages from anything
related to FOP to their own file.
In the logging.properties, I tried:
org.apache.fop.FileHandler = java.util.logging.FileHandler
org.apache.fop.FileHandler.pattern = logs/docgen.log
org.apache.fop.FileHandler.limit = 5000
org.apache.fop.FileHandler.formatter =
java.util.logging.SimpleFormatter
Where does org.apache.fop.FileHandler come from? Is that a class of
your own?
Note that changing logging.properties meddles with your global Java
defaults.
FOP uses Jakarta Commons Logging [http://commons.apache.org/logging/]
as a bridge to a specific logging implementation, which uses JDK
logging by default.
The Log implementation to be used can only be changed by setting a
system property, or by setting a configuration attribute on the
LogFactory, named "org.apache.commons.logging.Log"
FOP uses the default JCL LogFactoryImpl, and obtains class-based
Loggers that capture the log-output.
One way that /might/ work in an embedded context:
-> implement an org.apache.fop.apps.FileLog
-> set the above configuration attribute to match this implementation
on the org.apache.commons.LogFactory prior to starting FOP
Although this could lead to trouble when running multiple Fop
instances concurrently.
Since a lot (if not all) of FOP's loggers are statics, they are
initialized when the class is loaded, so two threads will share the
same loggers, and thus be writing to the same file. Make sure that
access is synchronized, and you will still end up with log messages
from different threads merged into the same file, unless you sort
that out yourself.
Probably the better way for FOP (well, it's a start):
-> implement a more generic org.apache.fop.apps.Log, that raises
events on an associated Listener
-> set the above config attribute on LogFactory prior to doing
anything else, except
-> offer the user a hook to plug in a custom event handler
The Log instance that raises the events should ideally be tied to the
FOUserAgent.
Still unsure how to fit in the static loggers :/
Maybe, to minimize the amount of refactoring, FTM we could do:
-> implement a simple org.apache.fop.apps.StaticLog
-> initialize all static loggers in static blocks and call
LogFactory.setAttribute() to use this type
The StaticLog.info() events and above, could get overloads that
accept an instance-based logger (the one tied to the user agent) on
which they register those events.
Should you decide to take steps in this direction, since this is
becoming a rather pressing matter, IMO, I'm willing to invest some
time in this as well.
HTH!
Cheers
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
