Re: Using Avalon/Logkit

Keiron Liddle wrote:
> 
> I think the are three possibilities:
> - use a generic logging package such as found in avalon, it is quite 
> possible to use the LogkitLogger, Log4JLogger and Jdk14Logger

True, but it introduces a dependency on Yet Another API (YAAPI). I'm 
generalizing here, but in my experience and from what I've picked up 
from other people in similar situations, is that keeping YAAPI bloat to 
a bare minimum is highly desirable.

> - use an interface

I see this as the most flexible method.

> - use methods on the user agent

I can see that this approach would provide some flexibility, but I'd 
suggest that the UA would be useful for obtaining an instance of the 
logging interface, rather than exposing methods for doing the actual 
error reporting itself, exactly as it does at the moment.

> The interface almost guarantees that we will need extra code to do 
> things that everyone else is doing. 

I don't think the amount of extra code would be too great. It would 
require 2 additional source files right now: one for the interface, one 
for the default Logkit implementation. Both would be tiny.

Re: Using Avalon/Logkit

Jeremias Maerki wrote:
> Logging is one thing. Error handling (like layout problems, image that
> can't be found etc.) is another. Right
As much as it at the moment. Obviously, errors need to be reported, and 
the most convenient way to do that is via a logging mechanism. In 
addition, it's often useful if there's some sort of callback mechanism 
so that the application, whether that be Driver or some code embedding 
FOP, can decide how to continue, *if* it should continue, and 
potentially, how to log the error.

Again, I think the way SAX does this, using org.xml.sax.ErrorHandler, is 
a convenient and flexible way to go.

> Logging: I'd go for the Avalon Logger interface which lets us freely
> choose the logging backend. We can even use the new ConsoleLogger or
> even NullLogger. 

Fair enough, but I maintain that it's still too much work for embedders. 
It is a right pain to have to have to include two more large libraries 
(Avalon and Logkit) with your application just to let FOP do logging, 
and it's too much functionality if your application has it's own logging 
mechanism already.

I'd suggest it would be a poor move to lock FOP into using one 
particular logging mechanism, especially when there are many 
alternatives out there: Log4J, 1.4's native logging mechanism, and all 
the existing, custom jobs, many of which have rabid supporters who won't 
use anything else. 8)

Serialization

Dear Fops,

I'm naïve about serialization (among other things.)  Can anyone tell me 
whether it is possible to serialize an instance of an inner class 
without implicitly serializing the containing class instance?

Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe <at> xml.apache.org
For additional commands, email: fop-dev-help <at> xml.apache.org

Re: userconfig.xml

Revelation:

Now I know why System.getProperties("user.dir") == "c:\windows\system32",
because that's where the Tomcat NT service must start from (not to mention
the java.exe that's in that folder also).  Hmm, what to do?  Ok, so how can
I have a not so relative path?

Conundrum:

How can I gain access to configuration info that resides in the web.xml file
for the SOAP servlet that calls my class, that in turn calls FOP?

--

David B. Bitton
david <at> codenoevil.com
www.codenoevil.com

Diversa ab illis virtute valemus.
----- Original Message -----
From: "Beer, Christian" <BEE <at> DIRON.de>
To: <fop-dev <at> xml.apache.org>
Sent: Tuesday, March 12, 2002 2:55 AM
Subject: AW: userconfig.xml

> > Yeah.  If I try File file = new File("userconfig.xml"), where
> > is it looking
> > relative to the class file requesting the file?
> >
> No, he is looking relative to the path you started java from.

LoggingHandler patch [was: Using Avalon/Logkit]

Guys,

To further to my suggestions about using an interface for logging in 
core FOP components, I've produced a working implementation of my 
suggestion. After a precursory test using the command line, the changes 
seem to work fine.

The patch, for the "fop-0_20_3" branch in CVS, and the two additional 
required source files are available at:

   <http://web.vee.net/fop/LoggingHandlerImpl-2002031300.jar>

The two added files are src/org/apache/fop/apps/LoggingHandler.java and 
src/org/apache/fop/apps/LogkitLoggingHandler.java. The former is the 
LoggingHandler interface, which has replaced any use of 
org.apache.log.Logger in core FOP code. The latter is an implementation 
of LoggingHandler which uses Logkit and is Loggable (for Avalon).

I've identified three applications which use assume the use of Logkit 
for logging: The command line app, the FOP task for Ant and 
TestConverter. All three have been modified to use LogkitLoggingHandler 
and hence function in the exact same fashion as before. In addition, if 
no LoggingHandler is explicitly set on Driver, it by default uses an 
instance of LogkitLoggingHandler, again to make it behave the same as 
before.

Embedders who do not wish to use Logkit for logging can write their own 
implementation of LoggingHandler and call Driver.setLogger() prior 
invoking Driver.render().

Re: Using Avalon/Logkit

Michael

> Jeremias Maerki wrote:
> > Logging is one thing. Error handling (like layout problems, image that
> > can't be found etc.) is another. Right
> As much as it at the moment. Obviously, errors need to be reported, and 
> the most convenient way to do that is via a logging mechanism. In 
> addition, it's often useful if there's some sort of callback mechanism 
> so that the application, whether that be Driver or some code embedding 
> FOP, can decide how to continue, *if* it should continue, and 
> potentially, how to log the error.
> 
> Again, I think the way SAX does this, using org.xml.sax.ErrorHandler, is 
> a convenient and flexible way to go.

Right, I think we agree here.

> > Logging: I'd go for the Avalon Logger interface which lets us freely
> > choose the logging backend. We can even use the new ConsoleLogger or
> > even NullLogger. 
> 
> Fair enough, but I maintain that it's still too much work for embedders. 
> It is a right pain to have to have to include two more large libraries 
> (Avalon and Logkit) with your application just to let FOP do logging, 
> and it's too much functionality if your application has it's own logging 
> mechanism already.
> 
> I'd suggest it would be a poor move to lock FOP into using one 
> particular logging mechanism, especially when there are many 
> alternatives out there: Log4J, 1.4's native logging mechanism, and all 

Re: LoggingHandler patch [was: Using Avalon/Logkit]

Michael

It's me again. I'm against that for the reasons layed out in my mail
from a few moments ago. I appreciate your effort but I think this is the
wrong way. I'm not a committer so my opinion doesn't count but I have
grown very fond of FOP to just be silent.

Cheers,
Jeremias Märki

mailto:jeremias.maerki <at> outline.ch

OUTLINE AG
Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
Tel. +41 41 317 2020 - Fax +41 41 317 2029
Internet http://www.outline.ch

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe <at> xml.apache.org
For additional commands, email: fop-dev-help <at> xml.apache.org

Re: Serialization

Hi Peter,

An inner class is actually a separate class that contains a reference to 
the containing class.
When the class is serialized it will serialize that reference (since I 
presume it is not transient).
If the class is static then it will not have a rreference to the 
containing class but that may not be suitable for other reasons.

On 2002.03.13 02:44 Peter B. West wrote:
> Dear Fops,
> 
> I'm naïve about serialization (among other things.)  Can anyone tell me 
> whether it is possible to serialize an instance of an inner class 
> without implicitly serializing the containing class instance?
> 
> Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe <at> xml.apache.org
For additional commands, email: fop-dev-help <at> xml.apache.org

Re: Using Avalon/Logkit

Hey Jeremias,

Jeremias Maerki wrote:
> 
> Right, I think we agree here.
> 

Cool.

> I'm exactly proposing this. I suggest you really have a look at Avalon.
> Avalon is very far from being another large library. Avalon Framework is
> 46K, LogKit is about 52K. Is that large?

Okay, my "two large libraries" remark was off-centre, but you really 
need to consider those who, for whatever reason, simply *can't* use 
Avalon. The reasons may be technical, political or otherwise, but if FOP 
forces people to use Avalon, then you will end up having people who 
won't use FOP because of it.

I'd love to have the time to get to know Avalon, but I just don't. In 
addition, the there is no way the particular project here at work I want 
to embed FOP in is going to use Avalon. Period. If the dependency on 
Avalon can't be broken, then there's very little chance FOP will be used 
for this project. Which I'll find very dissapointing, because I'm a big 
fan of FOP.

> org.apache.avalon.framework.logger.Logger is almost exactly what you did
> in your proposal, except that you introduce yet another API,

SV: problems with fo:external-graphic