Re: Using Avalon/Logkit

[Christian Geisert]

Michael Gratton wrote:

> 
[..]

 
> Anyway, a preliminary, but fully functional patch against the 
> "fop-0_20_3" branch can be found here: 
> . I just need to 


Committed.

> Mike.


Christian





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Using Avalon/Logkit

[Christian Geisert]

Jeremias Maerki wrote:

[..]

> That's a good point. Since I have a day off tomorrow and Michael is
> doing the logging stuff, I might look into the issue if FOP and JAXP
> might be able to get a bit closer together.

I have already a JAXP patch from Joerg, I just had no time to apply it
yet (I hope to do it on this weekend)

Christian



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Using Avalon/Logkit

[Keiron Liddle]

I meant just the cvs HEAD and the branch you are working on.

On 2002.03.15 08:52 Michael Gratton wrote:
> Cool, will do.
> 
> Out of curiosity, what was the name of that branch? Keiron mentioned 
> elsewhere that I'd probably want to patch both branches - one is 
> obviously going to be HEAD, the other I assumed was MAIN, but I'm not so 
> sure now..
> 
> Anyway, a preliminary, but fully functional patch against the 
> "fop-0_20_3" branch can be found here: 
> . I just need to 
> port it to the two other branches, and deal with both MessageHandler and 
> ToBeImplementedProperty, then it is ready to land.
> 
> I'll fix these things up sometime in the next few days..
> 
> Mike.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Using Avalon/Logkit

[Christian Geisert]

Michael Gratton wrote:
[..]

> Out of curiosity, what was the name of that branch? Keiron mentioned 
> elsewhere that I'd probably want to patch both branches - one is 
> obviously going to be HEAD, the other I assumed was MAIN, but I'm not so 
> sure now..


You get the "maintenance" branch with co -r fop-0_20_2-maintain xml-fop


> Anyway, a preliminary, but fully functional patch against the 
> "fop-0_20_3" branch can be found here: 
> . I just need to 
> port it to the two other branches, and deal with both MessageHandler and 


Two other branches? There are only two branches overall, one being the
"maintenance" branch, the other one is the "redesign" branch (MAIN).

> ToBeImplementedProperty, then it is ready to land.


I'll have a closer look at your patch on the weekend.

> I'll fix these things up sometime in the next few days..
> 
> Mike.

Christian


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Using Avalon/Logkit

[Michael Gratton]

Jeremias Maerki wrote:
 >
 > I'd extend Driver from AbstractLogEnabled and overwrite getLogger()
 > as done in the current version (maintbranch).

Cool, will do.

Out of curiosity, what was the name of that branch? Keiron mentioned 
elsewhere that I'd probably want to patch both branches - one is 
obviously going to be HEAD, the other I assumed was MAIN, but I'm not so 
sure now..

Anyway, a preliminary, but fully functional patch against the 
"fop-0_20_3" branch can be found here: 
. I just need to 
port it to the two other branches, and deal with both MessageHandler and 
ToBeImplementedProperty, then it is ready to land.

I'll fix these things up sometime in the next few days..

Mike.

-- 
Michael Gratton <[EMAIL PROTECTED]>
Recall Design 
s: 53 Gilbert Street Adelaide SA 5000 Australia
t: +61 8 8217 0500 f: +61 8 8217 0555



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Using Avalon/Logkit

[Jeremias Maerki]

On 14.03.2002 16:51:55 Joerg Pietschmann wrote:
> Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> > But I think you have some fears because you know too little of Avalon.
> 
> Well, thats nearly the core of the problem. Actually, in my case
> JAXP is the ultimate cause.
> 
> We started using XSLT in a servlet using JAXP, which defines
> its own facilities for dealing with problem reports (ErrorListener
> and such), configuration data and various customizations. After
> some struggling we successfully plumbed it into the environment.
> 
> Then there was the task to integrate FOP, which comes with yet
> another set of interfaces and other stuff to deal with problem
> reports and configuration data. It was to be expected that it
> wouldn't be the same as JAXP, but the relevant FOP/Avalon APIs
> are simply much too different from JAXP and noticable more complex.
> They may be superior to JAXP, but JAXP came first.

That's a good point. Since I have a day off tomorrow and Michael is
doing the logging stuff, I might look into the issue if FOP and JAXP
might be able to get a bit closer together.

> If i learned something during some 5+ years of interface design,
> it is that users get very upset if they think something should
> follow a common pattern but it doesn't. If they have to do similar
> things they expect to be able to do it in a similar way. Having
> to learn new ways is nearly as repugnant to them as paying taxes,
> even if its obvious there will be a benefit somewhere down the road.
> 
> It gets worse when developers have to tell their project managers
> they'll miss a deadline because they have to figure out another
> way of doing things they've already done in another context.
> Managers have a tendency to miss or ignore the "another context"
> part. This adds to the pressure.

Can't deny that.

> > We just
> > want to use a tiny part from Avalon where logging is concerned and an
> > embedder will not have to learn the Avalon way if he doesn't want to.
> 
> Note that configuration is also an issue. Note further that files
> are also parts of an interface, however well hidden.

Agreed. I forgot that point in the last few days. It's something I also
had in the back of my mind. FOP has its own configuration code at the
moment. This could be replaced by using Avalon's Configuration stuff
(maybe including that new CascadingConfiguration that I still have to
check out). I will need some configuration stuff when I'll have time to
bring the PostScript renderer up to production level and as soon as
we're going to use Avalon components there will be a need for
ComponentManager (or equivalent) and therefore for Avalon's
configuration mechanism.

> I met a Batik developer at the xml/webservices conference this
> week, and discussed this problem shortly as it applies to Batik
> too. I hope some ideas will emerge for converging to a consistent
> and easy to use interface for various kinds of processors.

That could be helpful. Maybe we already have something like that: Cocoon
has interfaces like that (Serializer? Just a thought!).

Cheers,
Jeremias Märki

mailto:[EMAIL PROTECTED]

OUTLINE AG
Postfach 3954 - Rhynauerstr. 15 - 6002 Luzern
Fon +41 (0)41 317 2020 - Fax +41 (0)41 317 2029
Internet http://www.outline.ch


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Using Avalon/Logkit

[Joerg Pietschmann]

Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> But I think you have some fears because you know too little of Avalon.

Well, thats nearly the core of the problem. Actually, in my case
JAXP is the ultimate cause.

We started using XSLT in a servlet using JAXP, which defines
its own facilities for dealing with problem reports (ErrorListener
and such), configuration data and various customizations. After
some struggling we successfully plumbed it into the environment.

Then there was the task to integrate FOP, which comes with yet
another set of interfaces and other stuff to deal with problem
reports and configuration data. It was to be expected that it
wouldn't be the same as JAXP, but the relevant FOP/Avalon APIs
are simply much too different from JAXP and noticable more complex.
They may be superior to JAXP, but JAXP came first.

If i learned something during some 5+ years of interface design,
it is that users get very upset if they think something should
follow a common pattern but it doesn't. If they have to do similar
things they expect to be able to do it in a similar way. Having
to learn new ways is nearly as repugnant to them as paying taxes,
even if its obvious there will be a benefit somewhere down the road.

It gets worse when developers have to tell their project managers
they'll miss a deadline because they have to figure out another
way of doing things they've already done in another context.
Managers have a tendency to miss or ignore the "another context"
part. This adds to the pressure.

> We just
> want to use a tiny part from Avalon where logging is concerned and an
> embedder will not have to learn the Avalon way if he doesn't want to.

Note that configuration is also an issue. Note further that files
are also parts of an interface, however well hidden.

I met a Batik developer at the xml/webservices conference this
week, and discussed this problem shortly as it applies to Batik
too. I hope some ideas will emerge for converging to a consistent
and easy to use interface for various kinds of processors.

Regards
J.Pietschmann

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Using Avalon/Logkit

[Jeremias Maerki]

Hey Michael

> Jeremias Maerki wrote:
> >   
> > I can help you with implementing or documenting, whatever you want.
> 
> Thanks for the offer, and thanks for the pointers. It's too late for me 
> start this now, I'll do it at work tomorrow (about 16hrs away) - gotta 
> love getting paid to work on OS projects.. ;)

Sleep well!

> I'm 100% confident I can sort this myself - it's exacly the same work 
> involved as the previous patch I posted, but if you're on hand to answer 
> any further questions that may arise, that would be useful.
> 
> WRT the last point, I'll make Driver implement LogEnabled and drop 
> Loggable. Given that (according to the javadocs on the Avalon web site) 
> LogEnabled exposes enableLogging(), not setLogger(), and does not 
> provide an analog for getLogger(), I'd suggest leaving any classes which 
> implement {get|set}Loggable() alone for now.
> 
> Sound okay?

Right, enableLogger() replaces setLogger(). And right, there's no
getLogger() on LogEnabled. I'm so used to having getLogger() provided by
AbstractLogEnabled (!) that I didn't remember. LogEnabled just defines a
contract on how to set the logger, not how to retrieve one. I'd extend
Driver from AbstractLogEnabled and overwrite getLogger() as done in the
current version (maintbranch). You just have to replace the LogKit setup
code in getLogger() by the ConsoleLogger.

Sounds okay. We can do these changes later if necessary.

Cheers,
Jeremias Märki

mailto:[EMAIL PROTECTED]

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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Using Avalon/Logkit

[Michael Gratton]

Hey Jeremias,

Jeremias Maerki wrote:
>   
> I can help you with implementing or documenting, whatever you want.

Thanks for the offer, and thanks for the pointers. It's too late for me 
start this now, I'll do it at work tomorrow (about 16hrs away) - gotta 
love getting paid to work on OS projects.. ;)

I'm 100% confident I can sort this myself - it's exacly the same work 
involved as the previous patch I posted, but if you're on hand to answer 
any further questions that may arise, that would be useful.

WRT the last point, I'll make Driver implement LogEnabled and drop 
Loggable. Given that (according to the javadocs on the Avalon web site) 
LogEnabled exposes enableLogging(), not setLogger(), and does not 
provide an analog for getLogger(), I'd suggest leaving any classes which 
implement {get|set}Loggable() alone for now.

Sound okay?

-- 
Michael Gratton <[EMAIL PROTECTED]>
Recall Design 
s: 53 Gilbert Street Adelaide SA 5000 Australia
t: +61 8 8217 0500 f: +61 8 8217 0555



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Using Avalon/Logkit

[Jeremias Maerki]

> Keiron Liddle wrote:
> > 
> > If you submit a patch for this it will be committed before you know it!
> 
> Excellent!
> 
> > No-one else has mentioned working on it so go ahead. It will probably 
> > need to be done on both branches but do whatever you want to.
> 
> Right, I'll get onto it, then.
> 
> Jeremias mentioned LogEnabled is replacing Loggable, is there any 
> concensus about moving Driver over to the new interface, making it 
> implement both, or just leaving it as-is for now? I'd suggest moving it 
> over, if not, then implementing both.

Michael, I've got a day off tomorrow, so I could help, too. No way at
the moment I can allocate time during work. The projects kill me.

I'd do the following:

- Remove logkit.jar as it's not really need when we're finished.
- Add avalon-framework.jar (We probably have to use a CVS snapshot
  because the current version 4.1.2 doesn't contain the ConsoleLogger,
  yet. CVS of framework is very stable.)
- Replace all occurences of org.apache.log.Logger with
  org.apache.avalon.framework.logger.Logger.
- Use org.apache.avalon.framework.logger.ConsoleLogger (prints to
  System.out) as default logger.
- There's a choice whether we want to use the LogEnabled interface or
  not (Forget Loggable). I mean after a quick look at the main branch
  I've seen a number of occurences where Keiron made setLogger/getLogger
  methods. These are candidates for implementing LogEnabled, because it
  defines just that. Where applicable we can extend AbstractLogEnabled
  which provides implementations for LogEnabled along with methods for
  getting child loggers etc. I'm for using LogEnabled wherever possible
  because it will help us later adopt the other contract interfaces from
  Avalon (which enables us the make use of ComponentManager (or its
  successor)).
  
I can help you with implementing or documenting, whatever you want. I'll
reserve my time tomorrow. Unfortunately I can't help a lot during the
next 8 hours because I'm going to visit a customer. I'm here for another
hour or so.

I hope this helps.

Cheers,
Jeremias Märki

mailto:[EMAIL PROTECTED]

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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Using Avalon/Logkit

[Michael Gratton]

Keiron Liddle wrote:
> 
> If you submit a patch for this it will be committed before you know it!

Excellent!

> No-one else has mentioned working on it so go ahead. It will probably 
> need to be done on both branches but do whatever you want to.

Right, I'll get onto it, then.

Jeremias mentioned LogEnabled is replacing Loggable, is there any 
concensus about moving Driver over to the new interface, making it 
implement both, or just leaving it as-is for now? I'd suggest moving it 
over, if not, then implementing both.

-- 
Michael Gratton <[EMAIL PROTECTED]>
Recall Design 
s: 53 Gilbert Street Adelaide SA 5000 Australia
t: +61 8 8217 0500 f: +61 8 8217 0555



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Using Avalon/Logkit

[Keiron Liddle]

On 2002.03.14 08:29 Michael Gratton wrote:
> If I write a patch to move FOP over to Avalon's Logger, will that patch 
> get comitted? Or is someone already working on it? Is there a schedule 
> for this?

If you submit a patch for this it will be committed before you know it!

No-one else has mentioned working on it so go ahead. It will probably need 
to be done on both branches but do whatever you want to.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Using Avalon/Logkit

[Jeremias Maerki]

Hi Michael

> Sigh, this is getting long, please bear with me here.

It doesn't make so much sense go on a lot further, but to make things
clear about Avalon and LogKit, I think I have to explain something about
Avalon:

There's LogKit, a logging facility, similar to Log4J for example. It has
a class named org.apache.log.Logger which FOP currently uses for logging.
As has nothing to do with Avalon except that it came out from that
project. LogKit does not use Avalon.

And then, there's org.apache.avalon.framework.logger.Loggable, an
interface (yes, I know it's deprecated) defining a contract on how to
provide logging for a component/object (not how to log per se). The
reason it's deprecated is that it's bound to LogKit.

Now, there's org.apache.avalon.framework.logger.LogEnabled which
replaces Loggable. It defines the same contract as Loggable except that
it's bound to the org.apache.avalon.framework.logger.Logger interface 
(which corresponds to your LoggingHandler).

Most probably FOP will just shift from using org.apache.log.Logger to
org.apache.avalon.framework.logger.Logger. This will remove logkit.jar
and add the somewhat smaller avalon-framework.jar.

As a aside to your previous mail: I agree with most of what you said.
But I think you have some fears because you know too little of Avalon. I
hope the above clears some of this. And I guarantee you that the Avalon
solution will in no way get more difficult than your proposal. We just
want to use a tiny part from Avalon where logging is concerned and an
embedder will not have to learn the Avalon way if he doesn't want to.

Cheers,
Jeremias Märki

mailto:[EMAIL PROTECTED]

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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Using Avalon/Logkit

[Michael Gratton]

Keiron Liddle wrote:
> 
> This is the fundamental problem with this argument.
> We are not talking about logkit, we are not talking about what code is 
> currently there.

Ahh, well, that's probably the key point I was missing then.

> Avalon has a logging interface:
> http://jakarta.apache.org/avalon/api/org/apache/avalon/framework/logger/Logger.html 
> 
> This is what we should use rather than making a copy of this same 
> interface. What more can I say?

Right, if that is the case, how can I help?

If I write a patch to move FOP over to Avalon's Logger, will that patch 
get comitted? Or is someone already working on it? Is there a schedule 
for this?

Thanks for sorting this out,
Mike.

-- 
Michael Gratton <[EMAIL PROTECTED]>
Recall Design 
s: 53 Gilbert Street Adelaide SA 5000 Australia
t: +61 8 8217 0500 f: +61 8 8217 0555



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Using Avalon/Logkit

[Keiron Liddle]

On 2002.03.14 02:43 Michael Gratton wrote:
> No, I defined an interface to a logging mechanism. Logkit *is* a logging 
> mechanism. There's a *huge*, *massive* difference here. I can't 
> emphasize that enough.

This is the fundamental problem with this argument.
We are not talking about logkit, we are not talking about what code is 
currently there.

Avalon has a logging interface:
http://jakarta.apache.org/avalon/api/org/apache/avalon/framework/logger/Logger.html

This is what we should use rather than making a copy of this same 
interface. What more can I say?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Using Avalon/Logkit

[Savino, Matt C]

> Look, does anyone else out there agree or disagree with me? Am I 
> flogging a dead horse? Barking up the wrong tree?

I tend to agree. I'm very happy with the output I get right now from FOP
.20.2 - especially the ms/page benchmarking. I also find useful the error
output and warnings, which go straight into my debugging logs like any other
Java piece of our beta app. 

As a relatively naive end user, I guess I'd like to hear why I need to adapt
my app to accomodate a new logging interface. If it's something FOP really
needs structurally then no problem. But if it's because I've been living in
a fool's paradise and need to wake up to real logging, then... well maybe
that's true, but I should probably learn it on my own. 

I promise to try out Avalon the second I get one, and get back to you.

-Matt





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Using Avalon/Logkit

[Michael Gratton]

Sigh, this is getting long, please bear with me here.

Jeremias Maerki wrote:
> 
> Ok, let's look at it that way: With your reasoning people who *can't*
> use Avalon *can't* use Cocoon, for example. But Cocoon only uses Avalon
> internally.

Err, as an application framework unto itself, I would have thought 
Cocoon would be the basis for building an application, not just 
something you'd pull in because you need to do some XML processing. In 
any case, if someone really could not use Avalon, and Cocoon exposed 
non-Avalon interfaces, then there would be no problem. The problem with 
FOP at the moment is *there is no non-Avalon interface*.

To be clear, I'm not talking about developing an application, I'm 
talking about embedding FOP into an existing framework which already has 
it's own logging, configuration and management services.

> What I want to say is the following: FOP users don't necessarily have to
> fiddle with Avalon since we can provide non-avalon interfaces for the
> outside world.

Users don't, but embedders do. I know because I just tried. Right now, 
no such non-Avalon interfaces exist. My proposal provides that 
non-Avalon interface for logging.

> Actually, your proposal and mine are exactly the same except that I'd
> like to use existing code. You introduce more FOP-specific stuff that we
> have to maintain and support.

Yep, and I still maintain that the once-off amounts of additional code 
(tiny) and the effort to maintain it (tiny, if any) is far offset by the 
benfit to emedders (great).

Actually, the amount of maintanence potentially goes *down*. When the 
Avalon interfaces inevitably change (which they already have: did you 
know that Loggable is deprecated?), at the moment you'll need to go 
through all of the FOP code and make those changes. Using an interface 
to it like LoggingHandler, you change one classs: the Logkit handler.

> When we introduce your logging idea (It's a good one I just happen to
> think there's a better one) we start something like that again.
> 

No, to my mind it is a different story - although if LoggingHandlers 
appeard in FOP for other logging mechanisms, such as 1.4's, it would be 
the same story. As I said before, I'm all for code reuse. By all means, 
use Batik for rendering SVG, use Excalibur's URIResolver, but of FOP is 
going to be widely used by embedders, you want to keep the amount of 
additional work required to embedd it down to a bare minimum.

>>The LogkitLoggingHandler class provides a transparent 
>>wrapper for using Logkit and Avalon with FOP. 
> 
> Avalon is no logger. It has logger facilities exactly for the same
> reason that we need one for FOP. So why don't we use Avalon's?

I didn't mean to imply it was - I was saying that the 
LogkitLoggingHandler can be used as a Avalon Loggable object - i.e., one 
that can do some logging, so it still fits nicely into the Avalon framework.

> That would mean LoggingHandler wraps Avalon's Logger interface which in
> turns wraps Logkit, Log4J, JDK14Logger etc. No benefit here, I think.

No, LoggkitLoggingHandler wraps Avalon's Logger, and implements the 
LoggingHandler interface. The benefit is to embedders who don't want to 
use Avalon - they provide their own implementation of LoggingHandler.

> I wouldn't trade in code reuse for a reduced number of jars. When this
> is really a problem you can always repack jars, so fop.jar, for
> example, includes the things needed from Avalon. (as I already said).

But I'm *not talking about less code reuse*.

It's *not* the number of jars that is the problem - it's the additional 
amount of code that a developer must be familiar with to effectively 
use, develop against, debug and support.

> Because Avalon's Logger interface is almost exactly the same as yours.
> And because we don't have to reinvent the wheel.

No, I defined an interface to a logging mechanism. Logkit *is* a logging 
mechanism. There's a *huge*, *massive* difference here. I can't 
emphasize that enough.

> Granted, we (may) have one more jar (avalon-framework.jar) but when we
> want to use Avalon some more (Caching, URI Resolving etc) we have to
> include it anyway (ok, probabaly another one: avalon-excalibur.jar). And
> FOP can concentrate on layout

Right, but embedders don't have to care about how FOP resolves a URI, or 
does it's caching, it's all internal, and as long it is kept purely 
internal, it does *not* matter. It's the external interfaces to FOP that 
embedders care about. For FOP to be used by developers, it *must* not 
impose undue constraints on them. Pigoenholing them into using a 
particular framework or forcing them to write translation layers from 
that framework to theirs *is* an undue constraint, regardless of how you 
attempt to justify it.

Take Mozilla for example. Moz uses some outstanding technologies, XPCOM, 
Gecko, Necko, libpr0n, XUL, XBL, Spidermonkey, etc, etc, etc. People use 
Moz for browsing the web, and they indirectly benefit from all of these 

Re: Using Avalon/Logkit

[Keiron Liddle]

On 2002.03.13 12:25 Joe Batt wrote:
> Logging within FOP is for debugging FOP.  It doesn't need to integrate 
> with anything.  As a user of FOP, I want it to be silent, just like my 
> JDBC driver is silent, just like my AWT layer is silent, just like my 
> messaging driver is silent.  As a developer of FOP, I want logging to 
> debug the FOP code.

I disagree. You may want it silent but users do need error messages. It 
also may need to be associated with a context and thread and placed in 
order with other messages.
Messages such as if the document could not be rendered due to some error 
in the fo or missing images etc.

It is obvious that no matter what solution is used then someone will 
complain. The real culprit is Sun for not putting logging in much ealier.
So what solution can we use that satisfies most people, is flexible and 
requires minimum code to maintain. The solution I keep coming up with is 
the avalon logging interface.

Now can we get back to what FOP is about, if I remember correctly 
something about formatting xsl:fo :)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Using Avalon/Logkit

[Jeremias Maerki]

Joe

So you would be one of the users who will be simply using some kind of /dev/null
logger (like org.apache.avalon.framework.logger.NullLogger). What we're
discussing here will enable you to just do that: Switch of logging
messages if you don't want them.

> (I am a user of FOP, not an active developer of FOP, but I do develop 
> apps that use FOP.)
> 
> I've been watching the discussion of logging within FOP rage for at 
> least 6 months now.  It seems pointless to me.
> 
> Logging within FOP is for debugging FOP.  It doesn't need to integrate 
> with anything.  As a user of FOP, I want it to be silent, just like my 
> JDBC driver is silent, just like my AWT layer is silent, just like my 
> messaging driver is silent.  As a developer of FOP, I want logging to 
> debug the FOP code.
> 
> Given the above is true, you could use something as simple as printlns 
> to s global print writer.  In debug mode it would go to the bit bucket. 
>  OK, I've used log4j, so I understand you may want something a little 
> more substantial than that, but why does the user care to integrate FOP 
> debugging into a larger logging structure?

For example to log any warnings should there be any problems later with
the printouts.
> 
> So far, any logging in FOP has been a problem for me.  It fills my logs, 
> and in the old version of FOP I am using, I can't turn it off without a 
> recompile.

So you're still stuck with MessageHandler. You could do something in
your code (just an example):
boolean enableFOPLogging = System.getProperty("fop.log").equals("true");
if (enableFOPLogging) {
MessageHandler.setOutputMethod(MessageHandler.SCREEN);
} else {
MessageHandler.setOutputMethod(MessageHandler.NONE);
}

That way you don't have to recompile.

Cheers,
Jeremias Märki

mailto:[EMAIL PROTECTED]

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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Using Avalon/Logkit

[arnd . beissner]

Joe Batt wrote:

> Given the above is true, you could use something as simple as printlns 
> to s global print writer.  In debug mode it would go to the bit bucket. 
> OK, I've used log4j, so I understand you may want something a little 
> more substantial than that, but why does the user care to integrate FOP 
> debugging into a larger logging structure?

I agree with all of your other points - I think you state the purpose
of logging very clearly. However, for this point, my answer
is: yes, the user does care, because:

1. If a solution is deployed at a user's site and the user observes problems,
   he or she wants to be able to reproduce the problems with logging turned
   on, because then the log file can be sent to the creator of the solution,
   whether that's a company or an open source initiative.

2. If a solution consists of multiple building blocks like FOP, and the
   user wants to turn on logging for the reason outlined under 1., then
   it's preferable that all building blocks share the same logging mechanism.

Nevertheless, I have another point about user-side logging that matches your
points nicely:

However much I like logging (I actually prefer logging and staring into
source code over using debuggers), I have one general problem with logging
in the "production code". Quite a number of developers seem to misunderstand
logging as a replacement for careful and thorough error handling and recovery.
In my opinion, logging (in production code) is always only a diagnostic
enhancement of error handling - not a replacement.

BTW: Yes, I do prefer log output over no error handling at all. 8-)

Arnd Beissner
--
Arnd Beißner IT-Engineering
Bahnhofstr. 3, 71063 Sindelfingen, Germany
Email: [EMAIL PROTECTED]
Phone: +49-7031-463458
Mobile: +49-173-3016917

Re: Using Avalon/Logkit

[Joe Batt]

(I am a user of FOP, not an active developer of FOP, but I do develop 
apps that use FOP.)

I've been watching the discussion of logging within FOP rage for at 
least 6 months now.  It seems pointless to me.

Logging within FOP is for debugging FOP.  It doesn't need to integrate 
with anything.  As a user of FOP, I want it to be silent, just like my 
JDBC driver is silent, just like my AWT layer is silent, just like my 
messaging driver is silent.  As a developer of FOP, I want logging to 
debug the FOP code.

Given the above is true, you could use something as simple as printlns 
to s global print writer.  In debug mode it would go to the bit bucket. 
 OK, I've used log4j, so I understand you may want something a little 
more substantial than that, but why does the user care to integrate FOP 
debugging into a larger logging structure?

So far, any logging in FOP has been a problem for me.  It fills my logs, 
and in the old version of FOP I am using, I can't turn it off without a 
recompile.

Joe


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Using Avalon/Logkit

[Jeremias Maerki]

> 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.

Ok, let's look at it that way: With your reasoning people who *can't*
use Avalon *can't* use Cocoon, for example. But Cocoon only uses Avalon
internally. Externally, it exposes its functionality as a Servlet, for
example. So when you use the WAR file you don't use Avalon directly. You
only edit some XML-based configuration files that happen to be loaded by
Avalon.

What I want to say is the following: FOP users don't necessarily have to
fiddle with Avalon since we can provide non-avalon interfaces for the
outside world. We've had that discussion on the list a few days ago. So
we get to the point of being able to use Avalon's facilities (only those
we need such as logging for the time being and probably more later).

Those who want to use a different logging facility can simply use one of
Avalon's implementations or write their own.

Actually, your proposal and mine are exactly the same except that I'd
like to use existing code. You introduce more FOP-specific stuff that we
have to maintain and support.

Hey, look at it that way. FOP uses Batik for SVG. They have their own
URIResolver. FOP has its own code for URI resolving. Cocoon (which uses
FOP) has its URI resolver that's being moved to Avalon Excalibur. And
they're all under the same hood (ASF). Ugly story.

When we introduce your logging idea (It's a good one I just happen to
think there's a better one) we start something like that again.

> 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.

I guess you still think Avalon is some big mammoth that will get in your
way. I don't think so, and the guys from Avalon would be too glad to
prove you the opposite. No, really. If all that you're after is logging
and you can live with an additional jar in the classpath, then Avalon
will not get in your way. It may even spare you of writing your own
logger adapter. You can even remove logkit.jar because it won't be
needed.

> 
> > org.apache.avalon.framework.logger.Logger is almost exactly what you did
> > in your proposal, except that you introduce yet another API,
> 
> Okay, in it's defence, the LoggingHandler API is very small, being one 
> interface large.

As is org.apache.avalon.framework.logger.Logger.

> The LogkitLoggingHandler class provides a transparent 
> wrapper for using Logkit and Avalon with FOP. 

Avalon is no logger. It has logger facilities exactly for the same
reason that we need one for FOP. So why don't we use Avalon's?

> For existing applications, 
> such as the command line app, it took (IIRC) one extra line and changing 
> three others to use the LoggingHandler mechanism, and it still uses 
> Logkit for the logging. If you want to use your own logger, then just 
> wrap it in a LogkitLoggingHandler and away you go. The amount of 
> additional work required to use the new interface is absolutely minimal, 
> and it will still work with Avalon, most likely by changing one single 
> line of code or configuration.

That would mean LoggingHandler wraps Avalon's Logger interface which in
turns wraps Logkit, Log4J, JDK14Logger etc. No benefit here, I think.

> 
> > We're talking about reusing mature code. And that sometimes means we have one
> > more jar to include.
> 
> I'm not talking about throwing it all away - you can still use all of 
> that existing code if you want. And sometimes one more jar is one too many.

I wouldn't trade in code reuse for a reduced number of jars. When this
is really a problem you can always repack jars, so fop.jar, for
example, includes the things needed from Avalon. (as I already said).

> > I'm disappointed that you're shooting against something you don't know.
> > 
> 
> I'll be the first to admit that I'm not familiar with Avalon, but I do 
> know I can't use it every project, even if I had the time to learn about 
> it, and I also know that if you start making core FOP functionality 
> depend on external services such as Avalon, a lot of embedders will go 
> elsewehre.

You don't need to learn Avalon. Really! We can use Avalon internally. We
can use Avalon's Logger i

Re: Using Avalon/Logkit

[Michael Gratton]

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,

Okay, in it's defence, the LoggingHandler API is very small, being one 
interface large. The LogkitLoggingHandler class provides a transparent 
wrapper for using Logkit and Avalon with FOP. For existing applications, 
such as the command line app, it took (IIRC) one extra line and changing 
three others to use the LoggingHandler mechanism, and it still uses 
Logkit for the logging. If you want to use your own logger, then just 
wrap it in a LogkitLoggingHandler and away you go. The amount of 
additional work required to use the new interface is absolutely minimal, 
and it will still work with Avalon, most likely by changing one single 
line of code or configuration.

> We're talking about reusing mature code. And that sometimes means we have one
> more jar to include.

I'm not talking about throwing it all away - you can still use all of 
that existing code if you want. And sometimes one more jar is one too many.

> I'm disappointed that you're shooting against something you don't know.
> 

I'll be the first to admit that I'm not familiar with Avalon, but I do 
know I can't use it every project, even if I had the time to learn about 
it, and I also know that if you start making core FOP functionality 
depend on external services such as Avalon, a lot of embedders will go 
elsewehre.
> Seems like we agree here.
> 

What I don't understand is how you can agree with using something like 
ErrorHandler but be against using a LoggingHandler, which works 
*precisely* in the same way. It's the *exact* same mechanism, but for 
logging.

If it still works with Avalon and Logkit, and works for embedders, how 
can you lose from such a win-win situation?

Mike.

-- 
Michael Gratton <[EMAIL PROTECTED]>
Recall Design 
s: 53 Gilbert Street Adelaide SA 5000 Australia
t: +61 8 8217 0500 f: +61 8 8217 0555



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Using Avalon/Logkit

[Jeremias Maerki]

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 
> the existing, custom jobs, many of which have rabid supporters who won't 
> use anything else. 8)

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? Avalon consists of several
subprojects (Framework, LogKit, Excalibur, Cornerstone, Phoenix and
Applications). Framework is the core which defines some simple contracts.
org.apache.avalon.framework.logger.Logger is almost exactly what you did
in your proposal, except that you introduce yet another API, while the
one from Avalon is mature and already has implementations for LogKit,
Log4J, JDK14Logging, Console logging und /dev/null logging. We're
talking about reusing mature code. And that sometimes means we have one
more jar to include. But what holds us back from extracting the classes
we need from avalon-framework.jar and include them in fop.jar. Not very
nice, but if it has to be that way... IMO software development today
goes more and more in the direction of reusing instead of doing it again
and again. You can build big complex application by using several
modules and plugging them together. A consequence of that is that we
have to get used to add some more jars to our classpaths. That's a small
effort when placed against the benefit of reusing mature software.

Here's the interface:
http://jakarta.apache.org/avalon/api/org/apache/avalon/framework/logger/Logger.html

Avalon won't stop at only providing a logging facility. FOP can profit
form several components especially in Excalibur by not having to
implement its own. For example the Cocoon team is currently moving some
components (like SourceResolver) over to Avalon Excalibur. As another
FOP could also profit from the use of the caching framework (for images).

A big genefit from using Avalon pattern is that it forces you to create
cleaner more reusable code. My company has profited a lot from adopting
Avalon.

I'm disappointed that you're shooting against something you don't know.

> > Error handling: We had a short discussion back in November. Doing that
> > in the user agent sounds good (it's the obvious place) although I can't
> > fully figure out yet if this solves everything we need. 
> 
> I agreee, FOP needs something like the ProblemListener you suggested in 
> the thread above.
> 
> As I suggested in an earlier email WRT logging, I think the UA is the 
> right place to get an instance of an ErrorHandler/ProblemListener, but 
> should not itself be responsible for that functionality. What should 
> happen (IMHO) is similar to the SAX model:
> 
> The application (Driver, or the embedding app) optionally supplies an 
> instance of ErrorHandler. If none is supplied, a default instance is 
> used which provides resonable default behavior (something like letting 
> warnings pass but throwing exceptions for errors). When an error 
> condition arises, the code should obtain that instance of ErrorHandler 
> from the UA or potentially elsewhere (but it should not just instantiate 
> it's own) and invoke the appropriate method on the handler, passing it 
> an appropriate exception object. The implementation then decides if it 
> is worth throwing that exception, and can do anything else it considers 
> worthwhile as well.
> Again, with this sort of mechansim, you get flexibility and control, and 
> it is very much embedding-friendly.

Seems like we agree here.

Cheers,
Jeremias Märki

mailto:[EMAIL PROTECTED]

OUTLINE AG
Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
Tel. +41 41 317 2020 - Fax +41 

Re: Using Avalon/Logkit

[Michael Gratton]

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)

> Error handling: We had a short discussion back in November. Doing that
> in the user agent sounds good (it's the obvious place) although I can't
> fully figure out yet if this solves everything we need. 

I agreee, FOP needs something like the ProblemListener you suggested in 
the thread above.

As I suggested in an earlier email WRT logging, I think the UA is the 
right place to get an instance of an ErrorHandler/ProblemListener, but 
should not itself be responsible for that functionality. What should 
happen (IMHO) is similar to the SAX model:

The application (Driver, or the embedding app) optionally supplies an 
instance of ErrorHandler. If none is supplied, a default instance is 
used which provides resonable default behavior (something like letting 
warnings pass but throwing exceptions for errors). When an error 
condition arises, the code should obtain that instance of ErrorHandler 
from the UA or potentially elsewhere (but it should not just instantiate 
it's own) and invoke the appropriate method on the handler, passing it 
an appropriate exception object. The implementation then decides if it 
is worth throwing that exception, and can do anything else it considers 
worthwhile as well.
Again, with this sort of mechansim, you get flexibility and control, and 
it is very much embedding-friendly.

Mike.

-- 
Michael Gratton <[EMAIL PROTECTED]>
Recall Design 
s: 53 Gilbert Street Adelaide SA 5000 Australia
t: +61 8 8217 0500 f: +61 8 8217 0555



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Using Avalon/Logkit

[Michael Gratton]

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.

> We also need to remember context and threading issues.
> 

True.

What I have in mind, after getting some sleep in on it, would be to 
define an interface for all logging, effectively just replacing 
references org.apache.log.Logger in the existing code with this 
interface. So getLogger() and setLogger() on Driver, Renderer, etc 
accept or return objects which implement this interface, for example.

I would suggest that this interface look somewhat like a cut down 
version of org.apache.log.Logger - one that only exposes logging methods 
such as info(), warn(), error(), etc. For the default implementation we 
  extend org.apache.log.Logger and have the new subclass implement this 
interface, or provide just provide a wrapper implementation. Lastly, 
modify Driver (and any other classes which provide default loggers) to 
instantiate the new default implementation class instead of a Logger, 
and you're done.

For extreme convenience, the interface's logging methods could be 
identical to those of Logger, so that the default impementation would be 
extremely basic, and the calls to methods on Logger in existing code 
would not need to be changed.

This mechanism is fast, conveient, and above all, flexible. It means 
that embedders can write their own, thin implementation of the logging 
interface and set that on Driver, rather than having to use Avalon and 
Logkit, but existing users see no change whatsoever, unless they are 
getting and modifying the default logger provided by Driver or similar. 
In those cases, it would be a small change to get it working again.

If no one has any other objections, I'll whip up a patch for review on 
the list.

Mike.

-- 
Michael Gratton <[EMAIL PROTECTED]>
Recall Design 
s: 53 Gilbert Street Adelaide SA 5000 Australia
t: +61 8 8217 0500 f: +61 8 8217 0555



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Using Avalon/Logkit

[Jeremias Maerki]

Logging is one thing. Error handling (like layout problems, image that
can't be found etc.) is another. Right?

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. :-)

Error handling: We had a short discussion back in November. Doing that
in the user agent sounds good (it's the obvious place) although I can't
fully figure out yet if this solves everything we need. Well, I should
think about that some more, then.
http://marc.theaimsgroup.com/?l=fop-dev&m=100642654705366&w=2

> If you can do it and it will be an improvement then I welcome your input.
> 
> 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
> - use an interface
> - use methods on the user agent
> 
> The interface almost guarantees that we will need extra code to do things 
> that everyone else is doing. The user agent could provide flexibility 
> while incorporating the first option.
> 
> We also need to remember context and threading issues.
> 
> On 2002.03.12 08:09 Michael Gratton wrote:
> > Personally, I'd suggest having core FOP logging services taken care of 
> > by something akin to org.xml.sax.ErrorHandler. This mechanism works 
> > quite nicely. FOP could provide a default implementation which uses 
> > Logkit/Avalon and embedders could provide their own.
> > 
> > Also, I'm prepared to put my money where my mouth is, so to speak. If 
> > people are happy with this approach, I'll gladly implement it over the 
> > next few days. I hope this conveys how important I think this issue is.
> > 
> > What does everyone say?

Cheers,
Jeremias Märki

mailto:[EMAIL PROTECTED]

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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Using Avalon/Logkit

[Keiron Liddle]

If you can do it and it will be an improvement then I welcome your input.

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
- use an interface
- use methods on the user agent

The interface almost guarantees that we will need extra code to do things 
that everyone else is doing. The user agent could provide flexibility 
while incorporating the first option.

We also need to remember context and threading issues.

On 2002.03.12 08:09 Michael Gratton wrote:
> Personally, I'd suggest having core FOP logging services taken care of 
> by something akin to org.xml.sax.ErrorHandler. This mechanism works 
> quite nicely. FOP could provide a default implementation which uses 
> Logkit/Avalon and embedders could provide their own.
> 
> Also, I'm prepared to put my money where my mouth is, so to speak. If 
> people are happy with this approach, I'll gladly implement it over the 
> next few days. I hope this conveys how important I think this issue is.
> 
> What does everyone say?
> 
> Mike.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Using Avalon/Logkit

[Michael Gratton]

Guys, I've just encountered this issue, so apologies for barging in late..

 > Jeremias Maerki wrote:
 >
 >> Joerg Pietschmann wrote:
>> 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.

I'm in the exact same boat here. We'd like to embed FOP but the 
configuration, management and logging environment we already have is 
more than sufficient without using another on top. It is a requirement 
of the project I'm on that all configuration is done via the central 
configuration mechanism, and all logging is to the project's logger. 
There's zero chance of using Avalon instead, and if we need to write 
translation layers between Avalon and what we already have, then 
embedding FOP will fall into the too hard basket, and we'll need to use 
somthing else. I'd dearly like to avoid having this happen.

>> 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

Ditto.

> 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.

I'm not sure what you mean here, when you say it could be "the other way 
around".

Personally, I'd suggest having core FOP logging services taken care of 
by something akin to org.xml.sax.ErrorHandler. This mechanism works 
quite nicely. FOP could provide a default implementation which uses 
Logkit/Avalon and embedders could provide their own.

Also, I'm prepared to put my money where my mouth is, so to speak. If 
people are happy with this approach, I'll gladly implement it over the 
next few days. I hope this conveys how important I think this issue is.

What does everyone say?

Mike.

-- 
Michael Gratton <[EMAIL PROTECTED]>
Recall Design 
s: 53 Gilbert Street Adelaide SA 5000 Australia
t: +61 8 8217 0500 f: +61 8 8217 0555



smime.p7s
Description: S/MIME Cryptographic Signature

RE: Using Avalon/Logkit

[Savino, Matt C]

I figured I'd go ahead and upadate my generator servlet to use all that log
code like the one in your new example. Then if still breaks, I will let you
know.

thanks a lot,
Matt



> -Original Message-
> From: Jeremias Maerki [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, February 27, 2002 11:50 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Using Avalon/Logkit
> 
> 
> > I just tried to plug in fop .20.3 to an existing app that 
> uses .20.2. I
> > included the new avalon jar in my classpath, but I still 
> get a logging
> > error. From an end user persepective, I would just like to 
> suggest that when
> > you add a new component between non-version build changes 
> that breaks the
> > old build or throws an error, please just point me to what 
> I need to do to
> > fix the problem (url?) right there in the error message. I 
> know I'm lazy,
> > but if there's any way this can be done it would make my 
> life a lot easier.
> 
> Could you tell us what exactly went wrong? Exceptions? Error messages?
> 
> Cheers,
> Jeremias Märki
> 
> mailto:[EMAIL PROTECTED]
> 
> 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: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
> 
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Using Avalon/Logkit

[Nicola Ken Barozzi]

From: "Joerg Pietschmann" <[EMAIL PROTECTED]>

> Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> > 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,
>
> Thanks for the help.
> Some comments on the concerns: I'm forced to use JDK 1.3 with JAXP1.1 and
> proprietary extensions for logging and configuration management (and other
> stuff i'll ignore now).
> I have to use the proprietary API to retrieve configurable options and
> want to feed them to a FOP instance. It's not easy for me to deploy a
config
> file, nor do i want to. My purposes would be served best if there were a
> processor class which took all configuration options as a Properties
bundle
> or through some generic interface like Transformer does. An avalon
component
> class encapsulating the simple processor class (or derived, for possible
> performance gains) could use this interface to pass options read from a
> config file, command line options or whatever.

Avalon can really help you here.
If FOP is completely Avalonized, you can plug in you own implementations of
logging or configuration Management without changing the core FOP code.
Avalon gives you these services using interfaces; this way any
implementation can be used.

> > 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.
>
> Well, adding is easier than subtracting. Apart from the interface, i
> don't want to have FOP looking around for files (URIs are ok, if i could
> supply code to resolve them).
>
> Can somebody  explain to me what could be gained if the processor
> was an avalon component by default (other than easy integration into
> the avalon framework, of course)?

It automatically gets the possibility of using all Avalon services.
Instead of explaining all possibilities, let me show you an example of the
Avalon way.

Let's say that you write your class:

public class MyClass {
  public MyClass{}
}

Now you want it to get created and managed by Avalon.
So you define it in a config file (or programmatically)and change it to:

public class MyClass implements Component{
  public MyClass{}
}

This way, when Avalon starts, it creates you class.

Now you want it to get some configuration.

public class MyClass implements Component, Configurable{
  public MyClass{}

  public void configure(Configuration conf)
  {
 //use conf here
  }
}

The Configuration it gets is gotten from *any* class that uses that
interface; Avalon will supply it to you.

Now you know that your configuration can change, so you write:

public class MyClass implements Component, Configurable, Reconfigurable{
  public MyClass{}

  public void configure(Configuration conf)
  {
 //use conf here
  }

  public void reconfigure(Configuration conf)
  {
 //use conf here
  }
}

now you want to add some init code:

public class MyClass implements Component, Configurable, Reconfigurable,
Initializable{
  public MyClass{}

  public void configure(Configuration conf)
  {
 //use conf here
  }

  public void reconfigure(Configuration conf)
  {
 //use conf here
  }

  public void initialize()
  {
 //initialization code
  }
}

now you want to add some lifecycle code:

public class MyClass implements Component, Configurable, Reconfigurable,
Initializable, Startable{
  public MyClass{}

  public void configure(Configuration conf)
  {
 //use conf here
  }

  public void reconfigure(Configuration conf)
  {
 //use conf here
  }

  public void initialize()
  {
 //initialization code
  }

  public void start()
  {
 //start code
  }

  public void stop()
  {
 //stop code
  }
}

now you want to logging:

public class MyClass implements Component, Configurable, Reconfigurable,
Initializable, Startable, Loggable{
  public MyClass{}

  public void configure(Configuration conf)
  {
 //use conf here
  }

  public void reconfigure(Configuration conf)
  {
 //use conf here
  }

  public void initialize()
  {
 //initialization code
  }

  public void start()
  {
 //start code
  }

  public void stop()
  {
 //stop code
  }

  public void getLogger(Logger logger)
  {
 //get logger here
  }
}

And so on.

Avalon is the glue that ties all together.

If you implement Composable, you get a ComponentManager that gives you other
Avalon components managed in the same way.
There are Avalon components for URI resolving, caching, storage, xslt, etc.
All these components are accessed by an interface, so you can out any
concrete impl behind.
In fact, Composable has:
 public Component lookup(String role);
Whatever you get must be cast to an interface.

--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-


---

Re: Using Avalon/Logkit

[Joerg Pietschmann]

Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> 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,

Thanks for the help.
Some comments on the concerns: I'm forced to use JDK 1.3 with JAXP1.1 and
proprietary extensions for logging and configuration management (and other
stuff i'll ignore now).
I have to use the proprietary API to retrieve configurable options and
want to feed them to a FOP instance. It's not easy for me to deploy a config
file, nor do i want to. My purposes would be served best if there were a
processor class which took all configuration options as a Properties bundle
or through some generic interface like Transformer does. An avalon component
class encapsulating the simple processor class (or derived, for possible
performance gains) could use this interface to pass options read from a
config file, command line options or whatever.

> 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.

Well, adding is easier than subtracting. Apart from the interface, i
don't want to have FOP looking around for files (URIs are ok, if i could
supply code to resolve them).

Can somebody  explain to me what could be gained if the processor
was an avalon component by default (other than easy integration into
the avalon framework, of course)?

Regards
J.Pietschmann

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Using Avalon/Logkit

[Jeremias Maerki]

> I just tried to plug in fop .20.3 to an existing app that uses .20.2. I
> included the new avalon jar in my classpath, but I still get a logging
> error. From an end user persepective, I would just like to suggest that when
> you add a new component between non-version build changes that breaks the
> old build or throws an error, please just point me to what I need to do to
> fix the problem (url?) right there in the error message. I know I'm lazy,
> but if there's any way this can be done it would make my life a lot easier.

Could you tell us what exactly went wrong? Exceptions? Error messages?

Cheers,
Jeremias Märki

mailto:[EMAIL PROTECTED]

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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Using Avalon/Logkit

[Nicola Ken Barozzi]

From: "Joerg Pietschmann" <[EMAIL PROTECTED]>

> "Nicola Ken Barozzi" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Using Avalon/Logkit

[Savino, Matt C]

I just tried to plug in fop .20.3 to an existing app that uses .20.2. I
included the new avalon jar in my classpath, but I still get a logging
error. From an end user persepective, I would just like to suggest that when
you add a new component between non-version build changes that breaks the
old build or throws an error, please just point me to what I need to do to
fix the problem (url?) right there in the error message. I know I'm lazy,
but if there's any way this can be done it would make my life a lot easier.

thx,
Matt Savino



> -Original Message-
> From: Alistair Hopkins [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, February 27, 2002 7:53 AM
> To: [EMAIL PROTECTED]
> Subject: RE: Using Avalon/Logkit
> 
> 
> 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: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
> 
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Using Avalon/Logkit

[Alistair Hopkins]

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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Using Avalon/Logkit

[Jeremias Maerki]

> Using JDK1.4 I wrap my logger calls in if statements
> 
> if(logger.isLoggable(Level.) {
>   logger.xxx();
> }
> 
> 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:[EMAIL PROTECTED]

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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Using Avalon/Logkit

[Jeremias Maerki]

> 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:[EMAIL PROTECTED]

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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Using Avalon/Logkit

[Alan McDade]

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:[EMAIL PROTECTED]]
Sent: 27 February 2002 13:45
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
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:[EMAIL PROTECTED]

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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Using Avalon/Logkit

[Jeremias Maerki]

> 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:[EMAIL PROTECTED]

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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Using Avalon/Logkit

[Joerg Pietschmann]

"Nicola Ken Barozzi" <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Using Avalon/Logkit Was: Re: [Understanding] Images [4]

[Nicola Ken Barozzi]

From: "Joerg Pietschmann" <[EMAIL PROTECTED]>

> Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> > By the way: What's the current agreement whether to use Avalon or not? I
> > mean, we're already using LogKit (which is cool).
>
> No, it's not cool unless done properly. I don't think users
> who want only pure FO processing should be forced to use
> another heavyweigth framework and logkit.

I've used Avalon framework in many projects, and IMHO it's not heavyweight.

Logkit is *very* light and fast, and I would humbly suggest to take a look
at the framework/logging classes that shields logging from implementation.
In this way any logger can be plugged in without changing code.

> I rather imagine something like the following layered
> architecture:
>
> 1. FOP core. Processes XML, either as SAX event stream by
>  supplying a content handler or by utilising the interface
>  javax.xml.transform.Source, into a renderer specific result
>  (probably a java.io.OutputStream, could even apply to a voice
>  renderer :-)
>  Do not rely on any hardcoded external files. Get configuration
>  via a java.util.Properties object or other explicit methods.

In my experience, using the avalon framework Configuration adds a *lot* of
flexibility and is very easy to use. Now it also has writing capability.
Using XML, it has a hierarchy.

>  Use a FOP owned interface like javax.transform.ErrorListener for
>  reporting errors and such, or perhaps even reuse ErrorListener
>  (somewhat odd, though).

In error reporting there are wo levels: user and developer.
The user gets notified by ErrorListener, the developer by logging. The user
could also want to put a logger as errorListener. Anyway avalon frameworl
logging shields from the logging implementation.

>  Use a javax.transform.URIResolver or a similar FOP owned
>  interface for resolving URIs (external graphics source, user
>  font file...).

There is already a tried and tested Avalon Component for this.

> 2. Intermediate layer with a class combining a transformer and
>  a FO processor instance (optional)
> 3. Class for embedding into the framework. Provides implementations
>  for the URIResolver and the ErrorListener, the latter redirecting
>  to the logging toolkit. May read external, user writable configuration
>  files. Uses framework for passing options and other parametrisations
>  from the outside (command line, servlet request, applet parameter...)

There is already a CLI util class in Avalon.

> It may be an idea to use the factory pattern like javax.transform:
>
> abstract classe FOProcessorFactory {
>   // get a new factory. factory may cache default properties for
>   // processors, fonts,...
>   static FOProcessorFactory newInstance();
>   // create a new processor. a FOProcessor instance is only good
>   // for one run, like a Transformer
>   abstract FOProcessor newFOProcessor();
>   abstract FOProcessor newFOProcessor();

There are ComponentManagers in Avalon, that handle lifecycle automatically.

>   // inherited to generated processors
>   abstract void setErrorListener(ErrorListener);
>   // inherited to generated processors. use also for example for
>   // loading default fonts while creating a new processor instance
>   abstract void setURIResolver(URIResolver);
>   // set attributes, like font file URIs or even compiled font
>   // classes
>   abstract void setAttribute(String name, Object value)
>   // perhaps a few shortcuts for transformations
>   abstract void setTransformation(Source xsl);
>   abstract void setTransformation(Templates);
>   // various get methods omitted :-)
> }
>
> abstract class FOProcessor {
>   abstract void setRenderer();
>   abstract void render(Source,OutputStream);
>
>   abstract void setErrorListener(ErrorListener);
>   abstract void setURIResolver(URIResolver);
>   abstract void setAttribute(String name, Object value)
>   // shortcuts
>   abstract void setTransformation(Source xsl);
>   abstract void setTransformation(Templates);
>   // extra shortcut (makes no sense for the factory)
>   abstract void setTransformation(Transformer);
> }

This is basically a definition of an interface of a FOProcessor, the main
avalon-style Component for FOP.
Using Excalibur ComponentManager, you just need to add a reference in the
xml configuration and it gets automatically setup, configured, and managed.

> If a transformation is set, the Source in render() is the original
> XML piped through the transformation. I'm not sure whether get/set/
> clearParameter for the transformation should be added to FOProcessor,
> fortunately, no output properties are necessary.

If it implements the Parametrizable interface of Avalon, the Parameters get
set automatically by Excalibur.
Same with Configurable.

IMHO, Avalon *really* helps in making a clean class structure and
Componentization.
I am finding it a bit difficult in getting the grasp of FOP specific stuff,
but understand something of Avalon, so I'm very willing to help in this
regard.

Cheers!
Ken

-