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 Tracey Zellmann <tr...@comcast.net> on 2006/03/04 20:44:55 UTC
Changing logging behavior in an embedded application.
I have dug through what documentation I can find, but it hasn't helped me,
so maybe the list can give me some guidance.
I have my application running successfully. I am using fop
0.91beta-bin-jdk1.4 It publishes a PDF using FOP within another java
application, not from the command line, so I believe you would call it
embedded.
I need to change the way logging messages are handled. Currently, I am
getting a large number of warning messages printed to the console. With
Jeremias Maerki's help, I can see they are caused my some namespace issues
with some imported svg images I am using from MS Visio. Essentially, they
can be ignored, and that is what I have been doing. However, next week, I
have to turn this over to the first wave of "normal" users, so I don't want
to overwhelm them with these messages.
I would like all messages to go to a log file, not the console. I would
prefer that warning level messages go to a file that is typically
overwritten, so they don't accumulate. Anything higher than warning should
go to another file which does append and accumulates the message history. I
am pretty sure I could handle this using Java's java.util.logging API.
However, I am not sure how to get hold of and change the current behavior of
FOP logging.
Can someone illuminate this for me?
Thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Changing logging behavior in an embedded application.
Posted by Ec...@tonbeller.com.
you are right the trunk version is fine. I am still using the 0.20 version
but I will soon upgrade
Eckard
Jeremias Maerki <de...@jeremias-maerki.ch>
07.03.2006 10:17
Bitte antworten an
fop-users@xmlgraphics.apache.org
An
fop-users@xmlgraphics.apache.org
Kopie
Thema
Re: Antwort: Re: Antwort: Re: Changing logging behavior in an embedded
application.
If the TTFReader is supposed to be used as an embedded component, it's
best to separate the logic from the command-line interface. System.out
calls would then not be permitted in the logic, only in the command-line
interface. I don't like when things are mixed. I've just had a look at
the code and as far as I can see, all log calls go to the logger, so it
would actually be only a matter of setting up the logging right in your
case. You may not even have to change anything. I did not remember that
the whole thing was so well cleaned-up already.
On 07.03.2006 10:06:31 Eckard_Buchner wrote:
> i could do something like this: Add a parameter -v (verbose) and doing
> system.out only when this parameter is set. Additionally there would be
a
> boolean property, because when I embed the reader I do not use the
main()
> method. Do you agree?
>
> Eckard
>
>
>
>
> Jeremias Maerki <de...@jeremias-maerki.ch>
> 07.03.2006 08:45
> Bitte antworten an
> fop-users@xmlgraphics.apache.org
>
>
> An
> fop-users@xmlgraphics.apache.org
> Kopie
>
> Thema
> Re: Antwort: Re: Changing logging behavior in an embedded application.
>
>
>
>
>
>
> You're welcome to improve TTFReader in FOP Trunk if it doesn't do
> exactly what you want it to do. TTFReader was never designed to be used
> as anything else than a command-line tool which is called once for each
> font. If people have additional needs we're gladly accepting patches
> against FOP Trunk.
>
> On 07.03.2006 08:23:56 Eckard_Buchner wrote:
> > > FOP does have a few System.out.println calls in its source code but
> > > these are only in places where those are ok, i.e. in command-line
> > > handling code
> >
> > IMHO this is not the case with the TTFReader. It tells you about each
> file
> > it reads and writes. If you convert a couple of files at once this is
a
> > little inconvenient. Maybe it should have a silent mode? BTW if you
> embed
> > the TTF Reader i would prefer getting exceptions when something goes
> wrong
> > rather than geting null return (and a stack trace in stdout)
>
> <snip/>
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Antwort: Re: Antwort: Re: Changing logging behavior in an embedded application.
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
If the TTFReader is supposed to be used as an embedded component, it's
best to separate the logic from the command-line interface. System.out
calls would then not be permitted in the logic, only in the command-line
interface. I don't like when things are mixed. I've just had a look at
the code and as far as I can see, all log calls go to the logger, so it
would actually be only a matter of setting up the logging right in your
case. You may not even have to change anything. I did not remember that
the whole thing was so well cleaned-up already.
On 07.03.2006 10:06:31 Eckard_Buchner wrote:
> i could do something like this: Add a parameter -v (verbose) and doing
> system.out only when this parameter is set. Additionally there would be a
> boolean property, because when I embed the reader I do not use the main()
> method. Do you agree?
>
> Eckard
>
>
>
>
> Jeremias Maerki <de...@jeremias-maerki.ch>
> 07.03.2006 08:45
> Bitte antworten an
> fop-users@xmlgraphics.apache.org
>
>
> An
> fop-users@xmlgraphics.apache.org
> Kopie
>
> Thema
> Re: Antwort: Re: Changing logging behavior in an embedded application.
>
>
>
>
>
>
> You're welcome to improve TTFReader in FOP Trunk if it doesn't do
> exactly what you want it to do. TTFReader was never designed to be used
> as anything else than a command-line tool which is called once for each
> font. If people have additional needs we're gladly accepting patches
> against FOP Trunk.
>
> On 07.03.2006 08:23:56 Eckard_Buchner wrote:
> > > FOP does have a few System.out.println calls in its source code but
> > > these are only in places where those are ok, i.e. in command-line
> > > handling code
> >
> > IMHO this is not the case with the TTFReader. It tells you about each
> file
> > it reads and writes. If you convert a couple of files at once this is a
> > little inconvenient. Maybe it should have a silent mode? BTW if you
> embed
> > the TTF Reader i would prefer getting exceptions when something goes
> wrong
> > rather than geting null return (and a stack trace in stdout)
>
> <snip/>
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Antwort: Re: Antwort: Re: Changing logging behavior in an embedded
application.
Posted by Ec...@tonbeller.com.
i could do something like this: Add a parameter -v (verbose) and doing
system.out only when this parameter is set. Additionally there would be a
boolean property, because when I embed the reader I do not use the main()
method. Do you agree?
Eckard
Jeremias Maerki <de...@jeremias-maerki.ch>
07.03.2006 08:45
Bitte antworten an
fop-users@xmlgraphics.apache.org
An
fop-users@xmlgraphics.apache.org
Kopie
Thema
Re: Antwort: Re: Changing logging behavior in an embedded application.
You're welcome to improve TTFReader in FOP Trunk if it doesn't do
exactly what you want it to do. TTFReader was never designed to be used
as anything else than a command-line tool which is called once for each
font. If people have additional needs we're gladly accepting patches
against FOP Trunk.
On 07.03.2006 08:23:56 Eckard_Buchner wrote:
> > FOP does have a few System.out.println calls in its source code but
> > these are only in places where those are ok, i.e. in command-line
> > handling code
>
> IMHO this is not the case with the TTFReader. It tells you about each
file
> it reads and writes. If you convert a couple of files at once this is a
> little inconvenient. Maybe it should have a silent mode? BTW if you
embed
> the TTF Reader i would prefer getting exceptions when something goes
wrong
> rather than geting null return (and a stack trace in stdout)
<snip/>
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Antwort: Re: Changing logging behavior in an embedded application.
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
You're welcome to improve TTFReader in FOP Trunk if it doesn't do
exactly what you want it to do. TTFReader was never designed to be used
as anything else than a command-line tool which is called once for each
font. If people have additional needs we're gladly accepting patches
against FOP Trunk.
On 07.03.2006 08:23:56 Eckard_Buchner wrote:
> > FOP does have a few System.out.println calls in its source code but
> > these are only in places where those are ok, i.e. in command-line
> > handling code
>
> IMHO this is not the case with the TTFReader. It tells you about each file
> it reads and writes. If you convert a couple of files at once this is a
> little inconvenient. Maybe it should have a silent mode? BTW if you embed
> the TTF Reader i would prefer getting exceptions when something goes wrong
> rather than geting null return (and a stack trace in stdout)
<snip/>
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Antwort: Re: Changing logging behavior in an embedded application.
Posted by Ec...@tonbeller.com.
> FOP does have a few System.out.println calls in its source code but
> these are only in places where those are ok, i.e. in command-line
> handling code
IMHO this is not the case with the TTFReader. It tells you about each file
it reads and writes. If you convert a couple of files at once this is a
little inconvenient. Maybe it should have a silent mode? BTW if you embed
the TTF Reader i would prefer getting exceptions when something goes wrong
rather than geting null return (and a stack trace in stdout)
Eckard
Jeremias Maerki <de...@jeremias-maerki.ch>
07.03.2006 08:05
Bitte antworten an
fop-users@xmlgraphics.apache.org
An
fop-users@xmlgraphics.apache.org
Kopie
Thema
Re: Changing logging behavior in an embedded application.
Hmm, FOP does not do anything special with warning messages as opposed
to debug- or info-level messages. If you managed you reroute all logging
to java.util.logger it's a matter of configuring that thing correctly.
FOP does have a few System.out.println calls in its source code but
these are only in places where those are ok, i.e. in command-line
handling code. Your other post about the Verdana font showed that you're
not calling FOP's command-line so everything does go through the logging
abstraction.
Did you specify a logging config file using
"-Djava.util.logging.config.file="
and properly set up the handlers?
On 06.03.2006 13:07:23 Tracey Zellmann wrote:
> Thanks.
>
> I had been to that page. I have got a basic solution. I can get
everything
> logged to a java.util.Logger, behaving the way I want. However, I am
still
> getting all the FOP WARNING messages coming to the console. I was able
to
> get a workable solution to that using redirection from the main command
that
> starts my Swing application, 2>fopMessages.txt sends all the command
warning
> messages to that file and overwrites each session. However, I would like
to
> find a cleaner approach.
>
> Is there a simple way to "turn off" the logging to the console?
>
> ----- Original Message -----
> From: "Jeremias Maerki" <de...@jeremias-maerki.ch>
> To: <fo...@xmlgraphics.apache.org>
> Sent: Monday, March 06, 2006 3:52 AM
> Subject: Re: Changing logging behavior in an embedded application.
>
>
> > Apache FOP uses Apache Jakarta Commons Logging as a logging
abstraction
> > kit. [1] should give you the basics and has links to further
information
> > on configuring logging the way you want it to behave. I hope that
helps.
> >
> > [1]
http://xmlgraphics.apache.org/fop/0.91/embedding.html#basic-logging
> >
> > On 04.03.2006 20:44:55 Tracey Zellmann wrote:
> >> I have dug through what documentation I can find, but it hasn't
helped
> >> me,
> >> so maybe the list can give me some guidance.
> >>
> >> I have my application running successfully. I am using fop
> >> 0.91beta-bin-jdk1.4 It publishes a PDF using FOP within another java
> >> application, not from the command line, so I believe you would call
it
> >> embedded.
> >>
> >> I need to change the way logging messages are handled. Currently, I
am
> >> getting a large number of warning messages printed to the console.
With
> >> Jeremias Maerki's help, I can see they are caused my some namespace
> >> issues
> >> with some imported svg images I am using from MS Visio. Essentially,
they
> >> can be ignored, and that is what I have been doing. However, next
week, I
> >> have to turn this over to the first wave of "normal" users, so I
don't
> >> want
> >> to overwhelm them with these messages.
> >>
> >> I would like all messages to go to a log file, not the console. I
would
> >> prefer that warning level messages go to a file that is typically
> >> overwritten, so they don't accumulate. Anything higher than warning
> >> should
> >> go to another file which does append and accumulates the message
history.
> >> I
> >> am pretty sure I could handle this using Java's java.util.logging
API.
> >> However, I am not sure how to get hold of and change the current
behavior
> >> of
> >> FOP logging.
> >>
> >> Can someone illuminate this for me?
> >>
> >> Thanks.
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Changing logging behavior in an embedded application.
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Hmm, FOP does not do anything special with warning messages as opposed
to debug- or info-level messages. If you managed you reroute all logging
to java.util.logger it's a matter of configuring that thing correctly.
FOP does have a few System.out.println calls in its source code but
these are only in places where those are ok, i.e. in command-line
handling code. Your other post about the Verdana font showed that you're
not calling FOP's command-line so everything does go through the logging
abstraction.
Did you specify a logging config file using "-Djava.util.logging.config.file="
and properly set up the handlers?
On 06.03.2006 13:07:23 Tracey Zellmann wrote:
> Thanks.
>
> I had been to that page. I have got a basic solution. I can get everything
> logged to a java.util.Logger, behaving the way I want. However, I am still
> getting all the FOP WARNING messages coming to the console. I was able to
> get a workable solution to that using redirection from the main command that
> starts my Swing application, 2>fopMessages.txt sends all the command warning
> messages to that file and overwrites each session. However, I would like to
> find a cleaner approach.
>
> Is there a simple way to "turn off" the logging to the console?
>
> ----- Original Message -----
> From: "Jeremias Maerki" <de...@jeremias-maerki.ch>
> To: <fo...@xmlgraphics.apache.org>
> Sent: Monday, March 06, 2006 3:52 AM
> Subject: Re: Changing logging behavior in an embedded application.
>
>
> > Apache FOP uses Apache Jakarta Commons Logging as a logging abstraction
> > kit. [1] should give you the basics and has links to further information
> > on configuring logging the way you want it to behave. I hope that helps.
> >
> > [1] http://xmlgraphics.apache.org/fop/0.91/embedding.html#basic-logging
> >
> > On 04.03.2006 20:44:55 Tracey Zellmann wrote:
> >> I have dug through what documentation I can find, but it hasn't helped
> >> me,
> >> so maybe the list can give me some guidance.
> >>
> >> I have my application running successfully. I am using fop
> >> 0.91beta-bin-jdk1.4 It publishes a PDF using FOP within another java
> >> application, not from the command line, so I believe you would call it
> >> embedded.
> >>
> >> I need to change the way logging messages are handled. Currently, I am
> >> getting a large number of warning messages printed to the console. With
> >> Jeremias Maerki's help, I can see they are caused my some namespace
> >> issues
> >> with some imported svg images I am using from MS Visio. Essentially, they
> >> can be ignored, and that is what I have been doing. However, next week, I
> >> have to turn this over to the first wave of "normal" users, so I don't
> >> want
> >> to overwhelm them with these messages.
> >>
> >> I would like all messages to go to a log file, not the console. I would
> >> prefer that warning level messages go to a file that is typically
> >> overwritten, so they don't accumulate. Anything higher than warning
> >> should
> >> go to another file which does append and accumulates the message history.
> >> I
> >> am pretty sure I could handle this using Java's java.util.logging API.
> >> However, I am not sure how to get hold of and change the current behavior
> >> of
> >> FOP logging.
> >>
> >> Can someone illuminate this for me?
> >>
> >> Thanks.
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Changing logging behavior in an embedded application.
Posted by Tracey Zellmann <tr...@comcast.net>.
Thanks.
I had been to that page. I have got a basic solution. I can get everything
logged to a java.util.Logger, behaving the way I want. However, I am still
getting all the FOP WARNING messages coming to the console. I was able to
get a workable solution to that using redirection from the main command that
starts my Swing application, 2>fopMessages.txt sends all the command warning
messages to that file and overwrites each session. However, I would like to
find a cleaner approach.
Is there a simple way to "turn off" the logging to the console?
----- Original Message -----
From: "Jeremias Maerki" <de...@jeremias-maerki.ch>
To: <fo...@xmlgraphics.apache.org>
Sent: Monday, March 06, 2006 3:52 AM
Subject: Re: Changing logging behavior in an embedded application.
> Apache FOP uses Apache Jakarta Commons Logging as a logging abstraction
> kit. [1] should give you the basics and has links to further information
> on configuring logging the way you want it to behave. I hope that helps.
>
> [1] http://xmlgraphics.apache.org/fop/0.91/embedding.html#basic-logging
>
> On 04.03.2006 20:44:55 Tracey Zellmann wrote:
>> I have dug through what documentation I can find, but it hasn't helped
>> me,
>> so maybe the list can give me some guidance.
>>
>> I have my application running successfully. I am using fop
>> 0.91beta-bin-jdk1.4 It publishes a PDF using FOP within another java
>> application, not from the command line, so I believe you would call it
>> embedded.
>>
>> I need to change the way logging messages are handled. Currently, I am
>> getting a large number of warning messages printed to the console. With
>> Jeremias Maerki's help, I can see they are caused my some namespace
>> issues
>> with some imported svg images I am using from MS Visio. Essentially, they
>> can be ignored, and that is what I have been doing. However, next week, I
>> have to turn this over to the first wave of "normal" users, so I don't
>> want
>> to overwhelm them with these messages.
>>
>> I would like all messages to go to a log file, not the console. I would
>> prefer that warning level messages go to a file that is typically
>> overwritten, so they don't accumulate. Anything higher than warning
>> should
>> go to another file which does append and accumulates the message history.
>> I
>> am pretty sure I could handle this using Java's java.util.logging API.
>> However, I am not sure how to get hold of and change the current behavior
>> of
>> FOP logging.
>>
>> Can someone illuminate this for me?
>>
>> Thanks.
>
>
> Jeremias Maerki
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Changing logging behavior in an embedded application.
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Apache FOP uses Apache Jakarta Commons Logging as a logging abstraction
kit. [1] should give you the basics and has links to further information
on configuring logging the way you want it to behave. I hope that helps.
[1] http://xmlgraphics.apache.org/fop/0.91/embedding.html#basic-logging
On 04.03.2006 20:44:55 Tracey Zellmann wrote:
> I have dug through what documentation I can find, but it hasn't helped me,
> so maybe the list can give me some guidance.
>
> I have my application running successfully. I am using fop
> 0.91beta-bin-jdk1.4 It publishes a PDF using FOP within another java
> application, not from the command line, so I believe you would call it
> embedded.
>
> I need to change the way logging messages are handled. Currently, I am
> getting a large number of warning messages printed to the console. With
> Jeremias Maerki's help, I can see they are caused my some namespace issues
> with some imported svg images I am using from MS Visio. Essentially, they
> can be ignored, and that is what I have been doing. However, next week, I
> have to turn this over to the first wave of "normal" users, so I don't want
> to overwhelm them with these messages.
>
> I would like all messages to go to a log file, not the console. I would
> prefer that warning level messages go to a file that is typically
> overwritten, so they don't accumulate. Anything higher than warning should
> go to another file which does append and accumulates the message history. I
> am pretty sure I could handle this using Java's java.util.logging API.
> However, I am not sure how to get hold of and change the current behavior of
> FOP logging.
>
> Can someone illuminate this for me?
>
> Thanks.
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org