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 Joerg Pietschmann <jo...@zkb.ch> on 2002/02/27 13:27:07 UTC
Re: Using Avalon/Logkit
"Nicola Ken Barozzi" <ba...@nicolaken.com> wrote:
> I've used Avalon framework in many projects, and IMHO it's not heavyweight.
Ok, scratch the heavyweight.
In order to clarify issues: I have to use FOP in an environment
which already provides logging, configuration management and life
cycle management. I don't want to look into another log file. I
don't want to write more config files. (There is also the fact
that said environment goes to great length to make augmenting
already provided functionality as complicated as possible). I have
already customized ErrorListeners, URIResolvers and such and i
want to reuse the functionality in the most straightforward way
possible. I don't want to write more customizations just for the
Apache logkit. In particular, i don't want to learn how to write
such customizations.
I don't want to prevent anyone from providing a FOP embedding
using logkit and avalon. I *want* however access to a core which
doesn't rely on yet another toolkit for common functionality and
fits as seemlessy as possible into a run time environment roughly
equivalent to the JDK 1.4 API (with emphasis on JAXP 1.1).
Regards
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Using Avalon/Logkit
Posted by Nicola Ken Barozzi <ba...@nicolaken.com>.
From: "Joerg Pietschmann" <jo...@zkb.ch>
> "Nicola Ken Barozzi" <ba...@nicolaken.com> wrote:
> > I've used Avalon framework in many projects, and IMHO it's not
heavyweight.
>
> Ok, scratch the heavyweight.
>
> In order to clarify issues: I have to use FOP in an environment
> which already provides logging, configuration management and life
> cycle management.
What is it?
> I don't want to look into another log file.
> I don't want to write more config files.
?
> (There is also the fact
> that said environment goes to great length to make augmenting
> already provided functionality as complicated as possible).
Avalon? I disagree. I've used it in a 10 months project. It saved me weeks
of work. And the architecture came out really clean.
> I have
> already customized ErrorListeners, URIResolvers and such and i
> want to reuse the functionality in the most straightforward way
> possible.
Using Avalon *is* reusing functionality.
> I don't want to write more customizations just for the
> Apache logkit. In particular, i don't want to learn how to write
> such customizations.
Customizations? I don't get you here.
> I don't want to prevent anyone from providing a FOP embedding
> using logkit and avalon.
Ok. Anyway, logging is a minor issue. If Avalon were logging, it would be
just logkit.
> I *want* however access to a core which
> doesn't rely on yet another toolkit for common functionality
Wait a second. If you need configuration, you *need* it. So you need to
write code to do it. So, what's the difference between importing Avalon code
or writing it yourself? What do you gain in writing it from scratch?
> and
> fits as seemlessy as possible into a run time environment roughly
> equivalent to the JDK 1.4 API (with emphasis on JAXP 1.1).
Sorry but I don't get you here. What is your measure of seamless?
I don't want this discussion to get into -just- logging, because IMO it's
not the point.
FOP (correct me if I'm wrong) is about transforming a fo tree in an area
tree, and then render this in many ways.
It's not about logging, configuration, lifecycle management, URI resolving,
etc.
But it needs them.
Avalon provides them, very well IMHO, and it's tried and tested code.
Why not use it?
My opinion is that using Avalon, FOP can concentrate on its core tasks, the
FO->AT->Render phases.
I would even dare go one step further.
FOP has basically two phases: FO2AT and AT2Rendering.
In Cocoon2, the first is a Transformation phase, the second a Serialization
phase. My crazy idea is that the new SAX driven FOP can be built on Cocoon
as a Transformer and a Serializer. All "utility" stuff is taken care of by
Cocoon. In this way we can concentrate on the *real* features of FOP. When
it works, we can then make it run in a more lightweight environment built on
Avalon.
For this, I seriously volunteer.
--
Nicola Ken Barozzi barozzi@nicolaken.com
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: Using Avalon/Logkit
Posted by Alistair Hopkins <al...@berthengron.co.uk>.
Could the Avalon jar shipped with Fop include
org.apache.avalon.framework.logger.Log4JLogger and
org.apache.avalon.framework.logger.Logger so it's easy for us to use log4j?
It's only a few kb extra and it means that we don't have to have lots of
avalon jars in the classpath, or have repackaged/custom versions of
Log4JLogger to get out of sync.
Alistair
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Using Avalon/Logkit
Posted by Jeremias Maerki <je...@outline.ch>.
> Using JDK1.4 I wrap my logger calls in if statements
>
> if(logger.isLoggable(Level.XXXX) {
> logger.xxx(<message>);
> }
>
> If you are privy to a better solution let me know.
No, that's fine. I didn't want to imply that you're writing bad code, I
just wanted to say that not all developers think about performance when
they produce logging code.
> In production code the 'if' nearly always evaluates to false and the logging
> is not performed. This requires the JVM to perform one method call, may even
> be inlined by a smart compiler. Putting a wrapper layer around this will
> require a call to a conversion method and then a call to the isLoggable().
> This at best doubles the number of method calls which are far more processor
> expensive than the body of the 'isLoggable()' itself. Should the
> 'isLoggable()' be inlined then this translation step becomes even more
> expensive.
>
> Incidentally our logging is stored in a central database after being
> transmitted across a network. The server pools these log records in memory
> before writing them to the database. This persistence is a performance
> problem does that make us bad programmers.
I'm not accusing you of being a bad programmers. I think you got me
wrong. Sorry for that. And furthermore, I don't like to start a
discussion about logging and performance. This discussion has been held
many time on the log4j and avalon mailing lists and can be looked up in
the archives. I don't have anything useful to add.
> I do not think that the gain in flexibility out-weighs the loses in
> performance. I would prefer to stick to log4j and spend the extra day
> learning the simple API rather than produce more inefficient code.
You always have to decide which one is more important. Sometimes it's
flexibility, sometime it's speed.
> I have to use 1.1.8 JDK(Personal Java 3.1) to program a Windows CE device,
> that does not mean I would argue against adopting a newer standard which
> would benefit the majority. I would think of a way to get round the problem
> rather than hold back the adoption of an obviously superior technology. If
> every body thought your way I would still be writing 'C' using command line
> tools. :)
Sorry, but I don't understand the relationship between my opinion and
your comment here.
Cheers,
Jeremias Märki
mailto:jeremias.maerki@outline.ch
OUTLINE AG
Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
Fon +41 41 317 20 20 - Fax +41 41 317 20 29
Internet http://www.outline.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: Using Avalon/Logkit
Posted by Alan McDade <al...@btinternet.com>.
Using JDK1.4 I wrap my logger calls in if statements
if(logger.isLoggable(Level.XXXX) {
logger.xxx(<message>);
}
If you are privy to a better solution let me know.
In production code the 'if' nearly always evaluates to false and the logging
is not performed. This requires the JVM to perform one method call, may even
be inlined by a smart compiler. Putting a wrapper layer around this will
require a call to a conversion method and then a call to the isLoggable().
This at best doubles the number of method calls which are far more processor
expensive than the body of the 'isLoggable()' itself. Should the
'isLoggable()' be inlined then this translation step becomes even more
expensive.
Incidentally our logging is stored in a central database after being
transmitted across a network. The server pools these log records in memory
before writing them to the database. This persistence is a performance
problem does that make us bad programmers.
I do not think that the gain in flexibility out-weighs the loses in
performance. I would prefer to stick to log4j and spend the extra day
learning the simple API rather than produce more inefficient code.
I have to use 1.1.8 JDK(Personal Java 3.1) to program a Windows CE device,
that does not mean I would argue against adopting a newer standard which
would benefit the majority. I would think of a way to get round the problem
rather than hold back the adoption of an obviously superior technology. If
every body thought your way I would still be writing 'C' using command line
tools. :)
Have a nice day
Alan
-----Original Message-----
From: Jeremias Maerki [mailto:jeremias.maerki@outline.ch]
Sent: 27 February 2002 14:09
To: fop-dev@xml.apache.org
Subject: Re: Using Avalon/Logkit
> One of the major criteria of a logging system is the minimal impact on
> performance. Surely having abstraction layers and implementation layers to
> provide logging will have an impact on this.
There's almost no performance penalty. Most performance is lost because
developers don't write their logging code well.
> As FOP is being redesigned could we not just adopt the 1.4 logging system.
> In time all JVM's will have this facility without additional jar's
> complicating/bloating our distributions. This logging system is not the
best
> but it will become universal.
Eventually, yes, it could become universal. But I hope you're aware of
how many people are still using JDK 1.1 today. The decision to drop JDK
1.1 support in FOP was something that not everyone welcomed. The same
will happen with the transition to JDK 1.4.
Cheers,
Jeremias Märki
mailto:jeremias.maerki@outline.ch
OUTLINE AG
Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
Fon +41 41 317 20 20 - Fax +41 41 317 20 29
Internet http://www.outline.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Using Avalon/Logkit
Posted by Jeremias Maerki <je...@outline.ch>.
> One of the major criteria of a logging system is the minimal impact on
> performance. Surely having abstraction layers and implementation layers to
> provide logging will have an impact on this.
There's almost no performance penalty. Most performance is lost because
developers don't write their logging code well.
> As FOP is being redesigned could we not just adopt the 1.4 logging system.
> In time all JVM's will have this facility without additional jar's
> complicating/bloating our distributions. This logging system is not the best
> but it will become universal.
Eventually, yes, it could become universal. But I hope you're aware of
how many people are still using JDK 1.1 today. The decision to drop JDK
1.1 support in FOP was something that not everyone welcomed. The same
will happen with the transition to JDK 1.4.
Cheers,
Jeremias Märki
mailto:jeremias.maerki@outline.ch
OUTLINE AG
Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
Fon +41 41 317 20 20 - Fax +41 41 317 20 29
Internet http://www.outline.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: Using Avalon/Logkit
Posted by Alan McDade <al...@btinternet.com>.
Hi All,
One of the major criteria of a logging system is the minimal impact on
performance. Surely having abstraction layers and implementation layers to
provide logging will have an impact on this.
As FOP is being redesigned could we not just adopt the 1.4 logging system.
In time all JVM's will have this facility without additional jar's
complicating/bloating our distributions. This logging system is not the best
but it will become universal.
Just my two pennies worth.
Alan
-----Original Message-----
From: Jeremias Maerki [mailto:jeremias.maerki@outline.ch]
Sent: 27 February 2002 13:45
To: fop-dev@xml.apache.org; joerg.pietschmann@zkb.ch
Subject: Re: Using Avalon/Logkit
> In order to clarify issues: I have to use FOP in an environment
> which already provides logging, configuration management and life
> cycle management. I don't want to look into another log file. I
> don't want to write more config files. (There is also the fact
> that said environment goes to great length to make augmenting
> already provided functionality as complicated as possible). I have
> already customized ErrorListeners, URIResolvers and such and i
> want to reuse the functionality in the most straightforward way
> possible. I don't want to write more customizations just for the
> Apache logkit. In particular, i don't want to learn how to write
> such customizations.
>
> I don't want to prevent anyone from providing a FOP embedding
> using logkit and avalon. I *want* however access to a core which
> doesn't rely on yet another toolkit for common functionality and
> fits as seemlessy as possible into a run time environment roughly
> equivalent to the JDK 1.4 API (with emphasis on JAXP 1.1).
Ok, I think that can be done, even when using Avalon in FOP. You propose
(I think) that we could provide an Avalon-Wrapper around FOP, but it
could also be the other way around. I'm sure that Avalon will not stand
in the way if we provide a simple interface similar to what you proposed.
Logging: As Nicola said, Avalon's logger-independent Logger interface
easily handles some of your concerns about JDK 1.4.
org.apache.avalon.framework.logger.Jdk14Logger already exists, for
example.
Cheers,
Jeremias Märki
mailto:jeremias.maerki@outline.ch
OUTLINE AG
Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
Fon +41 41 317 20 20 - Fax +41 41 317 20 29
Internet http://www.outline.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Using Avalon/Logkit
Posted by Jeremias Maerki <je...@outline.ch>.
> In order to clarify issues: I have to use FOP in an environment
> which already provides logging, configuration management and life
> cycle management. I don't want to look into another log file. I
> don't want to write more config files. (There is also the fact
> that said environment goes to great length to make augmenting
> already provided functionality as complicated as possible). I have
> already customized ErrorListeners, URIResolvers and such and i
> want to reuse the functionality in the most straightforward way
> possible. I don't want to write more customizations just for the
> Apache logkit. In particular, i don't want to learn how to write
> such customizations.
>
> I don't want to prevent anyone from providing a FOP embedding
> using logkit and avalon. I *want* however access to a core which
> doesn't rely on yet another toolkit for common functionality and
> fits as seemlessy as possible into a run time environment roughly
> equivalent to the JDK 1.4 API (with emphasis on JAXP 1.1).
Ok, I think that can be done, even when using Avalon in FOP. You propose
(I think) that we could provide an Avalon-Wrapper around FOP, but it
could also be the other way around. I'm sure that Avalon will not stand
in the way if we provide a simple interface similar to what you proposed.
Logging: As Nicola said, Avalon's logger-independent Logger interface
easily handles some of your concerns about JDK 1.4.
org.apache.avalon.framework.logger.Jdk14Logger already exists, for
example.
Cheers,
Jeremias Märki
mailto:jeremias.maerki@outline.ch
OUTLINE AG
Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
Fon +41 41 317 20 20 - Fax +41 41 317 20 29
Internet http://www.outline.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org