Can someone please give me some pointers on how to send my output to another file?
Currently I use the following which logs to the console:
Logger logger = new ConsoleLogger( ConsoleLogger.LEVEL_INFO); driver.setLogger( logger ); MessageHandler.setScreenLogger( logger );
I have tried to
probably mean not to use
SimpleLog but to provide a special implementation for command-line use.
At any rate, I don't agree with the way that SimpleLog is implemented.
Informational messages should go to System.out, errors to System.err.
Logging prefixes should be disabled. I've had to do the same
mean not to use
SimpleLog but to provide a special implementation for command-line use.
At any rate, I don't agree with the way that SimpleLog is implemented.
Informational messages should go to System.out, errors to System.err.
Logging prefixes should be disabled. I've had to do the same for Avalon
get any [INFO]
before each line, but
you can define the log level (normally quiet,
normal and verbose)
through command line switches. That'll work for most
CLI-users.
Errr, we're using Commons-Logging now. I don't think
we should wrap it. Perhaps we should switch to
System.out/.err
OK, forget it. I'm obviously worse at explaining things than I thought.
I don't have the time to chew this through. It should have been quick
and painless, but obviously it isn't. Hopefully, someone else has a
better solution.
I'm sorry for wasting your time writing this answer. Back to my JNI
Just giving my opinion--I also recognize that the
output interface is a bit rough, as Finn was saying,
and may still need some work, possibly along the lines
of what you were suggesting.
Glen
--- Jeremias Maerki [EMAIL PROTECTED] wrote:
OK, forget it. I'm obviously worse at explaining
things
Hi,
I didn't follow the discussion in the spring about command line -d and
commons-logging so I'm likely missing some important pieces, but I'm a
bit confused about the result.
If I attempt to render a fatally corrupt input fo file like:
fo:block/
, I get the expected SAXParseException
/show_bug.cgi?id=28237
[PATCH] Use the commons logging LogFactory also in Fop.java
--- Additional Comments From [EMAIL PROTECTED] 2004-04-19 11:30 ---
Glen,
One more...
3) setLevel() has been part of the Log4J API since before Logger was born; i.e.
when Logger was Category.
What Sun is up
/show_bug.cgi?id=28237
[PATCH] Use the commons logging LogFactory also in Fop.java
--- Additional Comments From [EMAIL PROTECTED] 2004-04-18 18:05 ---
--- Additional Comments From [EMAIL PROTECTED] 2004-04-18 03:27 ---
Glen, Simon, et al.
I have a problem with commons-logging
/show_bug.cgi?id=28237
[PATCH] Use the commons logging LogFactory also in Fop.java
--- Additional Comments From [EMAIL PROTECTED] 2004-04-18 19:28 ---
Glen,
On Sat, Apr 17, 2004 at 08:36:13AM -, [EMAIL PROTECTED] wrote:
--- Additional Comments From [EMAIL PROTECTED] 2004-04-17 08:36
/show_bug.cgi?id=28237
[PATCH] Use the commons logging LogFactory also in Fop.java
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
/show_bug.cgi?id=28237
[PATCH] Use the commons logging LogFactory also in Fop.java
--- Additional Comments From [EMAIL PROTECTED] 2004-04-18 23:19 ---
Two related questions:
If logging levels are supposed to be set through configuration files, then
1) why did the Sun guys put setLevel
/show_bug.cgi?id=28237
[PATCH] Use the commons logging LogFactory also in Fop.java
--- Additional Comments From [EMAIL PROTECTED] 2004-04-19 03:42 ---
1) why did the Sun guys put setLevel() in the API for java.util.logging?
2) why did the commons-logging guys put setLevel() in SimpleLog?
You
/show_bug.cgi?id=28237
[PATCH] Use the commons logging LogFactory also in Fop.java
--- Additional Comments From [EMAIL PROTECTED] 2004-04-17 08:21 ---
Created an attachment (id=11267)
another logging solution
/show_bug.cgi?id=28237
[PATCH] Use the commons logging LogFactory also in Fop.java
--- Additional Comments From [EMAIL PROTECTED] 2004-04-17 08:36 ---
Simon (and others),
For the remaining three issues remaining, please take a look at the patch I just
added.
1.) I removed the -debug
/show_bug.cgi?id=28237
[PATCH] Use the commons logging LogFactory also in Fop.java
--- Additional Comments From [EMAIL PROTECTED] 2004-04-18 03:27 ---
Glen, Simon, et al.
I have a problem with commons-logging. It deliberately leaves the configuration
to the user and the underlying logging
I think it's just setLevel() that you're looking for:
http://jakarta.apache.org/commons/logging/api/org/apache/commons/logging/impl/SimpleLog.html
Glen
Peter B. West wrote:
Glen,
I see that you have the move to commons-logging. I was encouraged by
this because of the support for 1.4 logging
and
check this.
Peter
Glen Mazza wrote:
I think it's just setLevel() that you're looking for:
http://jakarta.apache.org/commons/logging/api/org/apache/commons/logging/impl/SimpleLog.html
Peter B. West wrote:
I see that you have the move to commons-logging. I was encouraged by
this because
There appears a getLogger() that will take you to the native
java.util.logging instance:
http://jakarta.apache.org/commons/logging/api/org/apache/commons/logging/impl/Jdk14Logger.html
From there, you should be able to call the native setLevel() of the 1.4
logger:
http://java.sun.com/j2se/1.4.2
will still be able to log using common calls, but it is not tidy.
Peter
Glen Mazza wrote:
There appears a getLogger() that will take you to the native
java.util.logging instance:
http://jakarta.apache.org/commons/logging/api/org/apache/commons/logging/impl/Jdk14Logger.html
From there, you should
There is a release candidate for commons-logging v1.4, which includes
support for Lumberjack logging, i.e., Java1.4 style logging for 1.3
environments.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
For some reason interface Log (common to all the logging types) does not
have a setLevel()--somehow I think that was intentional, however.
After all, should FOP actually be setting the logging level? For
*embedded use*, that is done by the user--they choose the logger and the
level
One of the virtues of 1.4 logging is that (subject to security policies,
I think) the level can be set dynamically. If I run a *n*x shell
script, I can arrange to catch signals and, among other things, reset
the logging level on the fly. Java logging should offer the same
capability
Glen,
I see that you have the move to commons-logging. I was encouraged by
this because of the support for 1.4 logging, which I have started to use
in alt-design. When I looked at modifying the existing alt-design code
to use common-logging, however, I could find no way to set the logging
level
/show_bug.cgi?id=28237
[PATCH] Use the commons logging LogFactory also in Fop.java
--- Additional Comments From [EMAIL PROTECTED] 2004-04-09 10:09 ---
Glen,
(a) why place within isDebugEnabled() and isWarnEnabled()
conditionals, why does this matter?
To be as reticent as possible
/show_bug.cgi?id=28237
[PATCH] Use the commons logging LogFactory also in Fop.java
--- Additional Comments From [EMAIL PROTECTED] 2004-04-09 03:18 ---
Thanks for the explanation, Simon. I understand a lot more now and have
committed most of your patch, but with a few changes. Please take
/show_bug.cgi?id=28237
[PATCH] Use the commons logging LogFactory also in Fop.java
--- Additional Comments From [EMAIL PROTECTED] 2004-04-07 20:37 ---
Glen,
SimpleLog log = new SimpleLog(FOP);
log.setLevel(SimpleLog.LOG_LEVEL_INFO);
driver.setLogger(log
/show_bug.cgi?id=28237
[PATCH] Use the commons logging LogFactory also in Fop.java
Summary: [PATCH] Use the commons logging LogFactory also in
Fop.java
Product: Fop
Version: 1.0dev
Platform: PC
OS/Version: Linux
Status: NEW
/show_bug.cgi?id=28237
[PATCH] Use the commons logging LogFactory also in Fop.java
--- Additional Comments From [EMAIL PROTECTED] 2004-04-06 17:36 ---
Created an attachment (id=11157)
The patch as described
/show_bug.cgi?id=28237
[PATCH] Use the commons logging LogFactory also in Fop.java
--- Additional Comments From [EMAIL PROTECTED] 2004-04-06 21:48 ---
Simon, if I understand you correctly (and pardon me, I'm not a logging expert):
1.) With our current process of setting the logger in FOP.java
/show_bug.cgi?id=28044
Patch, Avalon Logging to Commons Logging Conversion.
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
As promised, I've changed the way the logger is fetched in the PDF
library and the font code. Instead of passing a Log instance from parent
to child (IoC, like with Avalon), logging-enabled classes fetch their
own logger via JCL's LogFactory. The code gets easier. I'm quite happy
On 02.04.2004 03:47:16 Glen Mazza wrote:
--- Jeremias Maerki [EMAIL PROTECTED] wrote:
I got home late today, so I didn't manage to finish
everything. I will
do that tomorrow morning.
Todos:
Actually, these todos were rather targeted at myself but I'm glad you
jumped in. THANKS!
Jeremias Maerki schrieb:
Yes, Axis uses JCL just as I wanted. Concerning the discovery things,
they are using Commons Discovery [1]. I'm not sure myself what the
intent/benefit is behind it but I'm pretty sure we don't have to do the
same. For the moment, I think the current approach is quite
Chris Bowditch wrote:
One additional thing is to add a system property to each startup
configuration in your IDE where you need to configure logging. Working
with Eclipse I've added...
-Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog
We would need to add
Glen Mazza wrote:
Chris Bowditch wrote:
snip/
-Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog
We would need to add this to FOP.sh or FOP.bat in CVS
It might be more efficient to store this information in the Ant build
file instead--I believe the .sh/.bat files just
the SimpleLog
logger from Commons Logging.
My current simplelog.properties looks like this:
org.apache.commons.logging.simplelog.showShortLogname=false
org.apache.commons.logging.simplelog.defaultlog=info
org.apache.commons.logging.simplelog.log.org.apache.fop.pdf=trace
Info about
I got home late today, so I didn't manage to finish everything. I will
do that tomorrow morning.
Todos:
- Figure out how best to configure the SimpleLog when using static
loggers in command line apps.
- Fix examples in examples/embedding
- Fix tests
- Update Gump descriptor to include the new
--- Jeremias Maerki [EMAIL PROTECTED] wrote:
I got home late today, so I didn't manage to finish
everything. I will
do that tomorrow morning.
Todos:
- Figure out how best to configure the SimpleLog
when using static
loggers in command line apps.
I'll let you start the cogitation here.
the logging is occur.
It appears that they created their own LogFactory to
centralize in one place the exact type of logger that
will be created. Also, they're doing something
security- and singleton discovery-related, I'm
unsure of its relevance for us, however--Axis has
requirements quite
/show_bug.cgi?id=28044
Patch, Avalon Logging to Commons Logging Conversion.
--- Additional Comments From [EMAIL PROTECTED] 2004-03-31 11:02 ---
Fantastic, I committed the change. I will next update the examples--and copy
what you do in the PDF libraries elsewhere if its advisable (Please
/show_bug.cgi?id=28044
Patch, Avalon Logging to Commons Logging Conversion.
--- Additional Comments From [EMAIL PROTECTED] 2004-03-31 12:05 ---
If you're talking about the Barcode generator (Barcode4J/Krysalis Barcode,
right?), that one doesn't need any interfacing over Avalon with FOP
/show_bug.cgi?id=28044
Patch, Avalon Logging to Commons Logging Conversion.
Summary: Patch, Avalon Logging to Commons Logging Conversion.
Product: Fop
Version: 1.0dev
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
/show_bug.cgi?id=28044
Patch, Avalon Logging to Commons Logging Conversion.
--- Additional Comments From [EMAIL PROTECTED] 2004-03-30 10:49 ---
Created an attachment (id=11047)
patch file, avalon logging-commons logging conversion
/show_bug.cgi?id=28044
Patch, Avalon Logging to Commons Logging Conversion.
--- Additional Comments From [EMAIL PROTECTED] 2004-03-30 11:37 ---
Hi Glen
I'm a bit surprised at the way you did the change. Like this I don't see any
benefit over Avalon-style logging. You still have to pass a lot
/show_bug.cgi?id=28044
Patch, Avalon Logging to Commons Logging Conversion.
--- Additional Comments From [EMAIL PROTECTED] 2004-03-30 13:22 ---
Glen,
the Avalon logger for the containerUtil that you mention. I think this is the
logger for Batik in the Transcoder. If we dont set it, does
/show_bug.cgi?id=28044
Patch, Avalon Logging to Commons Logging Conversion.
--- Additional Comments From [EMAIL PROTECTED] 2004-03-30 23:36 ---
Chris,
Good news--I fixed the issue you brought up below--never mind my previous
response. It turns out that ContainerUtil.enableLogging() [1
/show_bug.cgi?id=28044
Patch, Avalon Logging to Commons Logging Conversion.
--- Additional Comments From [EMAIL PROTECTED] 2004-03-30 23:51 ---
Created an attachment (id=11066)
new logger patch, disregard previous
/show_bug.cgi?id=28044
Patch, Avalon Logging to Commons Logging Conversion.
--- Additional Comments From [EMAIL PROTECTED] 2004-03-31 06:34 ---
ContainerUtil is just a little helper to avoid a lot of checks when setting up
Avalon-compliant objects. Avalon Framework defines a number
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
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
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
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
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
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
objects as well as some often
used services like logging, therefore boosting developer
productivity.
Correct. That's what it does.
In order to sell it to *users* of the
developed software, the framework should provide something
for them as well, like caching and saving configuration
J.Pietschmann wrote:
- If the FO objects are primarily data holders, why
have them at all, instead of using a standard DOM?
I believe standard DOM implementations are obviously too synchronized to
provide thread-safe access, while fo tree is built sequentially and is
read-only after its
Again, what else obvious components do we use? I'd like
to add stuff like PDF encryption, but I don't know enough
about this to decide how tight this has to be integrated
into the PDF renderer.
I've been having a look at encryption and components could be used
though to supply say no vs 40
/show_bug.cgi?id=11274
avalon-framework.jar in distribution does not support log4j logging
Summary: avalon-framework.jar in distribution does not support
log4j logging
Product: Fop
Version: 0.20.4
Platform: All
OS/Version: All
]
To: [EMAIL PROTECTED]
Sent: Friday, April 19, 2002 1:08 PM
Subject: Easier logging suppression for Driver?
Hey guys,
One thing I'm seeing coming up a lot on the small-use apps I'm writing is
that I don't need FOP to log its activity in apps moved to production. For
some reason, though
Hey guys,
One thing I'm seeing coming up a lot on the small-use apps I'm writing is that I don't
need FOP to log its activity in apps moved to production. For some reason, though,
Avalon 4 doesn't seem to have an org.apache.avalon.framework.logger.NullLogger
available to make logging
, April 19, 2002 1:08 PM
Subject: Easier logging suppression for Driver?
Hey guys,
One thing I'm seeing coming up a lot on the small-use apps I'm writing is
that I don't need FOP to log its activity in apps moved to production. For
some reason, though, Avalon 4 doesn't seem to have
@@ -37,6 +37,18 @@
driver.setRenderer(RENDER_PDF);
driver.run();]]/source
+ pYou also need to set up logging. Global logging for all FOP
+processes is managed by MessageHandler. Per-instance logging
+is handled by Driver. You want to set both using an implementation
Hi Mike,
I have committed this patch. Thanks a lot.
I think there might be a few classpaths that need updating but they can be
fixed when needed.
Thanks,
Keiron
On 2002.04.11 10:55 Michael Gratton wrote:
Guys,
Attached is a patch for the trunk to convert it over to using Avalon
Hello,
i have some questions about the status of the development of the logging
class
First of all some information about the jars i have in classpath
1 fop.jar from version fop-0.20.3
2 avalon-framework-4.1.2.jar from version Avalon-4.1.2
3 logkit.jar from version LogKit-1.0.1
I am a little
The change from LogKit to Avalon Logger has happened after the 0.20.3
release. The documentation on the website already reflects the changes
in CVS. There's no release yet with the new logging. You could download
the CVS-version, though.
snip/
I downloaded the current source code(fop-0.20.3
The change from LogKit to Avalon Logger has happened after the 0.20.3
release. The documentation on the website already reflects the changes
in CVS. There's no release yet with the new logging. You could download
the CVS-version, though.
Ok ,thx for this information, but our intranet
Michael Gratton wrote:
There was a problem with MessageHandler.error() in that patch. The
attached patch fixes that and makes MessageHandler.log() a bit more
readable. It also includes a fix for the outstanding
ToBeImplementedProperty problem - by using MessageHandler.
I've committed
Christian
Michael Gratton wrote:
There was a problem with MessageHandler.error() in that patch. The
attached patch fixes that and makes MessageHandler.log() a bit more
readable. It also includes a fix for the outstanding
ToBeImplementedProperty problem - by using MessageHandler.
The attached patch fixes the embedding examples so they compile again.
Mike.
--
Michael Gratton [EMAIL PROTECTED]
Recall Design http://www.recalldesign.com/
s: 53 Gilbert Street Adelaide SA 5000 Australia
t: +61 8 8217 0500 f: +61 8 8217 0555
Index: docs/examples/embedding/FopServlet.java
Michael Gratton wrote:
Attached is a patch (for the 'fop-0_20_2-maintain' branch) for
MessageHandler
There was a problem with MessageHandler.error() in that patch. The
attached patch fixes that and makes MessageHandler.log() a bit more
readable. It also includes a fix for the
This would require the element mappings to handle things a bit better,
fairly easy.
The other part is to setup some sort of render factory for foreign data
handling (in fo:instream-foreign-object and external graphics). This would
need a bit of work and time.
Another issue might be the size of
On Fri, 03 Aug 2001 15:34:26 Daniel Parker wrote:
And a good one. I'm not familiar with Velocity or it's particular
approach,
but the basic idea of separating logging interface from logging
implementation is sound. Components such as fop should not require a
particular logging
When FOP is a production ready library, I wont care for any FOP logging.
Logging in FOP now is only for debugging as far as I'm concerned. There
is no need for integration into other logging systems.
Think about how you use other libraries.
Joe
And a good one. I'm not familiar with Velocity or it's
particular approach,
but the basic idea of separating logging interface from logging
implementation is sound. Components such as fop should not require a
particular logging implementation, they should write to an interface and
allow
Keiron Liddle wrote:
On Thu, 02 Aug 2001 17:45:56 Carlos Villegas wrote:
I think it's possible to do in FOP what was done in Velocity. They have
a middleware that decouples Velocity from the specific logging toolkit.
So they have drivers for logkit and log4j and you can even write your
Isn't logging going to be a standard part of JDK 1.4? I thought that was
going to be based on IBM's Log4J. Is Avalon's logging based on that? If
not, should the 'standard' be considered? IIRC JDK 1.4 logging includes
the ability to log to syslog (on unix) and whatever the logging
So do others agree that this would be the way to go.
I do.
I have one question that hopefully someone knows answer (or knows who to
ask).
Since FOP is can be run in a number of ways (command line, in servlet
(cocoon), embedded), how can the logging be setup so that the fop logger
On Thu, 02 Aug 2001 08:56:55 Jeremias Maerki wrote:
Isn't logging going to be a standard part of JDK 1.4? I thought that
was
going to be based on IBM's Log4J. Is Avalon's logging based on that? If
not, should the 'standard' be considered? IIRC JDK 1.4 logging includes
the ability
that decouples Velocity from the specific logging toolkit.
So they have drivers for logkit and log4j and you can even write your
own one. This is a better choice when embedding FOP since you'd want to
use whatever logging system you've already have in place. I think it's
worth taking a look
80 matches
Mail list logo
