You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-users@xmlgraphics.apache.org by Michael Tracey Zellmann <tr...@gmail.com> on 2007/11/13 18:29:09 UTC
Capturing FOP logging message event in an embedded application using FOP 0.94
I have developed an application that generates PDFs of documentation in an
eclipse environment controlled by a variety of SWT widgets.
My customer would like his users to know when FOP has encountered a problem,
but give them a simple message. We are already trapping exceptions, so I am
interested in the kinds of events where FOP may generate a WARNING or SEVERE
logging message. Like - the text has exceeded the allowed width and is
overwriting another area, or the bookmark ids are pointing to a null
view-port, for instance. I know how to write a File Handler to route those
message to a file. Is there a way I can capture an event that will tell us
to pop a dialog to the user, and hopefully get part of the logging message ?
Re: Capturing FOP logging message event in an embedded application using FOP 0.94
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
(comments inline below)
On 16.11.2007 01:06:08 Andreas L Delmelle wrote:
<snip/>
> 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
Please note that this is something that will be addressed in the next
few months (it's going up in my priority list). I don't like just piping
log output to the user/caller. I have different ideas that should
address the needs better than just a massive stream of log output. I
like to differentiate between information for the FOP developer (logging)
and for the FOP user (processing feedback). Please track the following
Wiki page:
http://wiki.apache.org/xmlgraphics-fop/ProcessingFeedback
I'm probably getting to that in December or January at which point I'll
initiate a serious design discussion.
> 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.
For a client, I've hacked together something using ThreadLocals in Log4J
so you can grab all log output per rendering run (as long as we don't do
multi-threading inside FOP).
http://www.jeremias-maerki.ch/download/fop/log4j-threadlocal-appender.zip
You just have to implement ThreadLocalLogInterceptor to get the log
output. One instance per rendering run. Before you call FOP, you call
ThreadLocalLogSetup.installLogIntercepter() with your interceptor
instance in the same thread that you will run FOP. After the rendering
run, uninstall it again using ThreadLocalLogSetup.uninstallLogIntercepter().
This only works for Log4J so you have to configure Commons Logging to
use Log4J. But this could easily be adapted to work with Commons Logging
directly. But maybe that helps as a work-around until we have a proper
processing feedback mechanism.
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Capturing FOP logging message event in an embedded application using FOP 0.94
Posted by Andreas L Delmelle <a_...@pandora.be>.
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: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Capturing FOP logging message event in an embedded application using FOP 0.94
Posted by Michael Tracey Zellmann <tr...@gmail.com>.
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
but that does not work.
I can say
java.util.logging.FileHandler.pattern = logs/docgenAll.log
and that will send all logging messages from any source to the file
docgenALL -
hwoever, I don't want all the messages - only ones froma class in the fop
hierarchy.
What should I do to accomplish this ?
On Nov 13, 2007 3:04 PM, Andreas L Delmelle <a_...@pandora.be> wrote:
> On Nov 13, 2007, at 18:29, Michael Tracey Zellmann wrote:
>
> Hi
>
> > I have developed an application that generates PDFs of
> > documentation in an eclipse environment controlled by a variety of
> > SWT widgets.
> >
> > My customer would like his users to know when FOP has encountered a
> > problem, but give them a simple message. We are already trapping
> > exceptions, so I am interested in the kinds of events where FOP may
> > generate a WARNING or SEVERE logging message. Like - the text has
> > exceeded the allowed width and is overwriting another area, or the
> > bookmark ids are pointing to a null view-port, for instance. I know
> > how to write a File Handler to route those message to a file. Is
> > there a way I can capture an event that will tell us to pop a
> > dialog to the user, and hopefully get part of the logging message ?
>
> I fear you have stumbled upon a well-known shortcoming of FOP 0.9x:
> the error-reporting is not really what it should be. We all know it,
> but haven't found the time so far to take steps towards implementing
> something better, so exceptions and log messages are all there is to
> catch FTM... :(
>
>
> Sorry
>
> Andreas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
>
Re: Capturing FOP logging message event in an embedded application using FOP 0.94
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Nov 13, 2007, at 18:29, Michael Tracey Zellmann wrote:
Hi
> I have developed an application that generates PDFs of
> documentation in an eclipse environment controlled by a variety of
> SWT widgets.
>
> My customer would like his users to know when FOP has encountered a
> problem, but give them a simple message. We are already trapping
> exceptions, so I am interested in the kinds of events where FOP may
> generate a WARNING or SEVERE logging message. Like - the text has
> exceeded the allowed width and is overwriting another area, or the
> bookmark ids are pointing to a null view-port, for instance. I know
> how to write a File Handler to route those message to a file. Is
> there a way I can capture an event that will tell us to pop a
> dialog to the user, and hopefully get part of the logging message ?
I fear you have stumbled upon a well-known shortcoming of FOP 0.9x:
the error-reporting is not really what it should be. We all know it,
but haven't found the time so far to take steps towards implementing
something better, so exceptions and log messages are all there is to
catch FTM... :(
Sorry
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org