Re: Using Avalon/Logkit
Michael Gratton wrote: [..] Anyway, a preliminary, but fully functional patch against the fop-0_20_3 branch can be found here: http://web.vee.net/fop/AvalonLogger-patch-20020315.jar. I just need to Committed. Mike. Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Using Avalon/Logkit
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: http://web.vee.net/fop/AvalonLogger-patch-20020315.jar. 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
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: http://web.vee.net/fop/AvalonLogger-patch-20020315.jar. 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
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 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
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 http://www.recalldesign.com/
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
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
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: http://web.vee.net/fop/AvalonLogger-patch-20020315.jar. 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 http://www.recalldesign.com/ 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
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 http://www.recalldesign.com/ 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
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
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
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
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 technologies. Developers also
Re: Using Avalon/Logkit
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
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
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 http://www.recalldesign.com/ 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
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
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-devm=100642654705366w=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
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 http://www.recalldesign.com/ 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 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 41 317 2029 Internet http://www.outline.ch
Re: Using Avalon/Logkit
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 http://www.recalldesign.com/ 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
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
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
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
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
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
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
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
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
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 Was: Re: [Understanding] Images [4]
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(Renderer enumeration);
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(Renderer enumeration);
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
--
Nicola Ken Barozzi
