Re: Logging for FOrayFont
Victor Mote wrote:
OK. Still I miss your point.
Well, I think loggin is much overrated and it is really overdone
in FOP.
Fatal errors are fatal errors. Just throw an exception and let
someone else figure out what to do. Some examples from the FOP
code where logging doesn't help:
public int getValue() {
log.error(getValue() called on + enumProperty + length);
return 0;
}
if ((bfSet MAXSET) != 0) {
// Warning: minmax, resetting max to min
log.error(forcing max to min in LengthRange);
}
maximum = minimum;
public Source resolve(String href, String base)
throws javax.xml.transform.TransformerException {
try {
// the above failed, we give it another go in case
// the href contains only a path then file: is assumed
absoluteURL = new URL(file: + href);
} catch (MalformedURLException mfue) {
log.error(Error with URL ' + href + ': +
mue.getMessage(), mue);
return null;
}
Especially the latter gets a Duh!, because of:
public Source resolveURI(String uri) {
...
if (uriResolver != null) {
try {
source = uriResolver.resolve(uri, getBaseURL());
} catch (TransformerException te) {
log.error(Attempt to resolve URI ' + uri + ' failed: , te);
}
}
if (source == null) {
// URI Resolver not configured or returned null, use default
// resolver
try {
source = foURIResolver.resolve(uri, getBaseURL());
} catch (TransformerException te) {
log.error(Attempt to resolve URI ' + uri + ' failed: , te);
}
}
FOP needs a facility to notify a user about warnings, recoverable
errors and progress reports. There may be a separate facility to
provide debug for developers and yet another to provide out-of-band
results like ressource ussage statistics and number of generated pages.
I don't think that generously sprinkling log.stuff() statements all
over the place is the best solution to the problems above, even though
this seems to fit.
J.Pietschmann
ForayFont dependency in graphics commons; was: Logging for FOrayFont
Hi all, So this is a tricky one. I really feel like I'm getting in the way of FOP stuff, but on the other hand as far as I can see the ForayFont stuff would have almost zero advantage for Batik's use of the PDF Transcoder. This is because Batik has to do all of it's own text layout and it currently does this using the Java2D Platform Fonts, TrueType (referenced from CSS), and of course SVG fonts. Right now there are a few 'trivial' text cases that are handled by the PDF Graphics2D 'drawString' stuff that might benefit but basically, as far as I can see, this would - for Batik - be another very low functionality external dependency. That said I know that currently one of the stumbling blocks for extracting the PDFGraphics2D from the rest of FOP is the the font subsystem. There is a bit of an inherent conflict between using Graphics2D as a 'high level transcoding' API and advanced font/text handling. Currently, the list of Java2D fonts (from GraphicsEnvironment is totally independent of the Graphics2D). Now of course the current state of text output for PDF is fairly abysmal from Batik (anything beyond very simple text is done as shapes), but fixing that would probably be a huge piece of work. I personally would lean towards leaving the font-subsystem as pluggable. BTW as far as the PsuedoLogger stuff is concerned this is fine with me (and is actually my preferred way to handle this). It doesn't force any logger on me, yet one can plug it into any existing logging system with a fairly trivial piece of code. Although this may not matter depending on how we approach Font support. Jeremias Maerki wrote: I got a little shock when I realized a problem I didn't think of when we discussed moving FOP components over to XML Graphics Commons. We said we would try to remove logging code from these basic components entirely. Now, I forgot to consider the decision to use FOrayFont made earlier. The external dependency on FOrayFont also would be a problem in itself because the Batik side has strong feelings against external dependencies. We need to think about what to do about this WRT the PDF and PS transcoders. Optimized text painting in these two transcoders depends a lot on the font subsystem. Chris Bowditch wrote: Ouch! The FORayFont integration offers a hugh functional benefit over the current Font code, so it would be a real shame to lose it. IIRC Thomas was saying that he was against dependencies that don't yield any functional benefit, i.e. logging and avalon framework. Since FORayFont does have functional benefits for both projects perhaps it won't be such a problem for Batik to include it. But I guess that is up the Batik team to decide.
Re: ForayFont dependency in graphics commons; was: Logging for FOrayFont
Thanks for chiming in, Thomas. It should be possible to have that pluggable for Batik. After all, the text bridge mechanism from Batik provides an ideal way to plug that functionality in. A few random notes on the topic: - The PDF library has dependencies on the font subsystem, so we would need to make sure that Batik without special text handling in PDF will work without the font subsystem classes present in the classpath. - Maybe something could be done to embed the fonts of the Java2D origin as Type 3 fonts. Keiron has left a TODO item about that somewhere. Shouldn't be that hard to do. - There IS benefit in painting text as text instead of shapes. You get a lot of speed and a much smaller file size. - I have the impression that the FOP-grown text bridges currently don't work though I haven't investigated closely, yet. I hope we'll find a good way to handle this. I'll start copying/migrating components over to Commons as soon as the first FOP preview release is out. On 06.09.2005 14:31:38 Thomas DeWeese wrote: Hi all, So this is a tricky one. I really feel like I'm getting in the way of FOP stuff, but on the other hand as far as I can see the ForayFont stuff would have almost zero advantage for Batik's use of the PDF Transcoder. This is because Batik has to do all of it's own text layout and it currently does this using the Java2D Platform Fonts, TrueType (referenced from CSS), and of course SVG fonts. Right now there are a few 'trivial' text cases that are handled by the PDF Graphics2D 'drawString' stuff that might benefit but basically, as far as I can see, this would - for Batik - be another very low functionality external dependency. That said I know that currently one of the stumbling blocks for extracting the PDFGraphics2D from the rest of FOP is the the font subsystem. There is a bit of an inherent conflict between using Graphics2D as a 'high level transcoding' API and advanced font/text handling. Currently, the list of Java2D fonts (from GraphicsEnvironment is totally independent of the Graphics2D). Now of course the current state of text output for PDF is fairly abysmal from Batik (anything beyond very simple text is done as shapes), but fixing that would probably be a huge piece of work. I personally would lean towards leaving the font-subsystem as pluggable. BTW as far as the PsuedoLogger stuff is concerned this is fine with me (and is actually my preferred way to handle this). It doesn't force any logger on me, yet one can plug it into any existing logging system with a fairly trivial piece of code. Although this may not matter depending on how we approach Font support. Jeremias Maerki wrote: I got a little shock when I realized a problem I didn't think of when we discussed moving FOP components over to XML Graphics Commons. We said we would try to remove logging code from these basic components entirely. Now, I forgot to consider the decision to use FOrayFont made earlier. The external dependency on FOrayFont also would be a problem in itself because the Batik side has strong feelings against external dependencies. We need to think about what to do about this WRT the PDF and PS transcoders. Optimized text painting in these two transcoders depends a lot on the font subsystem. Chris Bowditch wrote: Ouch! The FORayFont integration offers a hugh functional benefit over the current Font code, so it would be a real shame to lose it. IIRC Thomas was saying that he was against dependencies that don't yield any functional benefit, i.e. logging and avalon framework. Since FORayFont does have functional benefits for both projects perhaps it won't be such a problem for Batik to include it. But I guess that is up the Batik team to decide. Jeremias Maerki
Re: Logging for FOrayFont
On Mon, Sep 05, 2005 at 09:35:26PM +0200, Jeremias Maerki wrote: As I said, widely differing views between Batik and FOP about this. In my own personal opinion, I'm with you. From the POV of XML Graphics Commons we have a problem. We've voted on the plan for Commons where we said that we'd try to remove the dependency on Commons Logging. If there is a problem with that, the right place to raise this is [EMAIL PROTECTED] That means that those Commons components will have to define their own interface to which they are willing to send logging events, just like ForayFont does. FOP will have to implement all interfaces defined by the libraries it uses. It should do so on top of a Commons Logger instance, to preserve Commons Logging user configurability. It would of course be easier if all components would use a standard interface like Commons Logging. But that is not going to happen in this world. My remark about runtime information to debug a system configuration is inspired by a TeX system, which needs to load many component files. I realized that it uses a different method. Its resolver library does indeed no logging. Instead, there is a stand-alone front end to it that the user must run separately to obtain configuration debugging information. For example, when in my LaTeX run class X is not loaded as I expect, I use this app (kpsewhich) to find out where the resolver library thinks the class X is. It also displays search path information, and information about how the search path is constructed from the configuration file and the built in path components. Regards, Simon On 05.09.2005 21:15:50 Simon Pepping wrote: snip/ I am not sure that I understand everything that is being said here. But I am alarmed when I hear that basic libraries, in this case the FontServer, shouldn't log anymore. In my experience a font system requires powerful logging, in order to expose runtime behaviour to the systems manager or end user. Configuring font systems and understanding why a piece of font software does not use it as you expect, is a hard task that requires suitable runtime information from the software. Jeremias Maerki -- Simon Pepping home page: http://www.leverkruid.nl
RE: Logging for FOrayFont
Simon Pepping wrote: It would of course be easier if all components would use a standard interface like Commons Logging. But that is not going to happen in this world. FWIW, I am not opposed to having FOray use Commons Logging instead of a home-grown interface. But that is actually an external dependency as well, so that was not an option. And from the standpoint of a component developer, you have to ask yourself how often you can afford to switch from Avalon to Commons to ... It would (maybe) help some if java itself would endorse an interface for this purpose. Victor Mote
Re: Logging for FOrayFont
Jeremias Maerki wrote: I got a little shock when I realized a problem I didn't think of when we discussed moving FOP components over to XML Graphics Commons. We said we would try to remove logging code from these basic components entirely. Now, I forgot to consider the decision to use FOrayFont made earlier. The external dependency on FOrayFont also would be a problem in itself because the Batik side has strong feelings against external dependencies. We need to think about what to do about this WRT the PDF and PS transcoders. Optimized text painting in these two transcoders depends a lot on the font subsystem. Ouch! The FORayFont integration offers a hugh functional benefit over the current Font code, so it would be a real shame to lose it. IIRC Thomas was saying that he was against dependencies that don't yield any functional benefit, i.e. logging and avalon framework. Since FORayFont does have functional benefits for both projects perhaps it won't be such a problem for Batik to include it. But I guess that is up the Batik team to decide. snip/ Chris
Re: Logging for FOrayFont
I'm satisfied with your explanations. Please just add a LEVEL_DEBUG constant and I'm OK with your interface. OK, I have added the constant LEVEL_DEBUG back, and have also added a new one called LEVEL_TRACE. PLEASE NOTE: LEVEL_DEBUG is now equal to LEVEL_FINER (it previously was equal to LEVEL_FINEST), and LEVEL_TRACE has been set equal to LEVEL_FINEST. These changes have been made to better accommodate what I understand the Commons Logging levels to be. This makes the Avalon mapping look like this: FINEST debug FINER debug FINEinfo CONFIG info INFOinfo WARNING warn SEVERE error That's fine for me! Thank you, Vincent
Re: Logging for FOrayFont
On 05.09.2005 17:05:48 Victor Mote wrote: Jeremias Maerki wrote: I got a little shock when I realized a problem I didn't think of when we discussed moving FOP components over to XML Graphics Commons. We said we would try to remove logging code from these basic components entirely. Now, I forgot to consider the decision to use FOrayFont made earlier. The external dependency on FOrayFont also would be a problem in itself because the Batik side has strong feelings against external dependencies. We need to think about what to do about this WRT the PDF and PS transcoders. Optimized text painting in these two transcoders depends a lot on the font subsystem. Well, the little change I just made removes entirely any dependency on Avalon in any FOray code, except for the fact that Ant seems to need it for logging (needed for creating hyphenation patterns and such). There is no longer any Avalon code in FOrayFont. In fact, that was the primary motivation for making the change. The Avalon Logger interface would have been quite a sufficient solution for anything that FOray needs, and, since it is an interface, adapters could be written from it to anything else, just as Vincent and I have been discussing for the PseudoLogger interface. Yeah, yet another generic logger abstraction interface. Sigh. Aside from that, a thought about the aXSL APIs: Being an ex-Avaloner SoC (separation of concerns) is a big concern to me. The functional API of a package should IMO actually not deal with (or rather expose) logging at all. It's a separate concern. I'm ever growing more cofident that developer-oriented logging should be done through a static logging facility (like Commons Logging) and that end-user-oriented logging needs to operate per processing run (like Avalon Logger) but not necessarily through a standard logging abstraction interface, but rather an application-specific one that provides exactly what the application needs to send feedback to the end-users. In that light, a PDF or font library shouldn't expose any logging facilities at all or at least to static logging that is externally configured. First, do you understand that the FOrayFont library does not expose any logging facilities to the client, but instead asks the client to expose the logging facilities to it? Yes. Sorry for the not quite accurate wording plus a typo. Let's try again: [a work interface] shouldn't expose any logging specifica (as they are a separate concern, see Avalon's LogEnabled interface or newer dependency injection systems). If developer-oriented logging is absolutely necessary I prefer static logging (like Commons Logging or Log4J) today. A PseudoLogger is required (but can be passed null) in the FontServer constructor That's an implementation detail and not a problem. It has nothing to do with the API. FontServer is an interface in the API and you are talking about the implementation of FontServer here, I assume. and is required in a method in FontConsumer. But FontConsumer is implemented on the client side, in which the client application tells FOray about itself. This method getPseudoLogger() is what caught my purist's eye in the first place. It breaks IoC. Second, why should FOray limit its clients to only use static logging? If the client has to expose a static logging mechanism to FOray in order to get static logging to work, what can possibly be wrong with exposing a non-static logging mechanism to FOray? Right now, FOray doesn't care whether static or non-static logging is used. Why should it? Exactly. Why should it? If you remove all logging concerns from the work interface you don't do any assumptions about how logging is done. The presence of getPseudoLogger(), though, produces a strong emphasis on non-static logging. Third, lets define the concern. importantMy understanding of Separation of Concerns in this case is that FOrayFont owns the concern that a message needs to be logged, and that the client application owns the concern of how that logging should be accomplished./important In order to maintain that Separation of Concerns, one of two things must happen: 1. The client must tell the component how stuff should be logged. 2. The server must tell the client what should be logged. This means some logging-related stuff will appear in the interface between the two. Not IMO. It can be an implementation detail. See more below. The design considerations are as follows: 1. FOrayFont needs to be able to log messages. For whom? For the developer or for the end-user? Because that's what I've learned during the past months: That it should be well divided between the two audiences. The speciality is that the developer doesn't need a logger per processing run (i.e. non-static logging) and the end-user often needs more than just pure Strings through a generic logging interface. Note that this is not yet reality
Re: Logging for FOrayFont
On Mon, Sep 05, 2005 at 07:33:33PM +0200, Jeremias Maerki wrote: On 05.09.2005 17:05:48 Victor Mote wrote: Jeremias Maerki wrote: The design considerations are as follows: 1. FOrayFont needs to be able to log messages. For whom? For the developer or for the end-user? Because that's what I've learned during the past months: That it should be well divided between the two audiences. The speciality is that the developer doesn't need a logger per processing run (i.e. non-static logging) and the end-user often needs more than just pure Strings through a generic logging interface. Note that this is not yet reality in FOP but I believe it will be soon. Now, I know this has the potential to spark a heated debate again and it raises question marks about the FOrayFont integration, but ATM I really don't know what to do about it right now. I just realized we have a problem here. I/we made promises on general@xmlgraphics.apache.org to try to remove logging and other external dependencies (like Avalon) for the common components because that's something which is very important to the Batik side. So, then, how are those components supposed to log anything? Or, if they are to log using their own static stuff, how can this be configured by the client? Eventually such basic libraries shouldn't log anything anymore. That's the big dilemma I'm sitting in, the one I need to find a way out of. Anyway, ways to remove the necessity to log are: unit tests and stabilization. The problem is getting rid of something so extremely handy but actually completely unnecessary for something basic like a PDF or font library. But I'd never want to get rid of the ability to log in a complex system like a layout engine. I am not sure that I understand everything that is being said here. But I am alarmed when I hear that basic libraries, in this case the FontServer, shouldn't log anymore. In my experience a font system requires powerful logging, in order to expose runtime behaviour to the systems manager or end user. Configuring font systems and understanding why a piece of font software does not use it as you expect, is a hard task that requires suitable runtime information from the software. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: Logging for FOrayFont
Jeremias Maerki wrote: I'm ever growing more cofident that developer-oriented logging should be done through a static logging facility (like Commons Logging) and that end-user-oriented logging needs to operate per processing run (like Avalon Logger) but not necessarily through a standard logging abstraction interface, but rather an application-specific one that provides exactly what the application needs to send feedback to the end-users. That's a major part of the points at the end of http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/200508.mbox/[EMAIL PROTECTED] The idea is that FOP sends certain events (or messages) to the User Agent interface and let the app specific user agent implementation sort out whether it wants to log it, throw an exception, show a message box, whatever. The static debug/trace mechanism is a welcomed refinement, I'd thought of exposing the logger from the user agent to the rest of the code for this purpose. It is quite possible that the event signalling methods proposed in the post above need to be split up further. /me ducks. Hehe. I've also thought again that designing certain interfaces (and piling them on each other) must be really really fun. J.Pietschmann
Re: Logging for FOrayFont
As I said, widely differing views between Batik and FOP about this. In my own personal opinion, I'm with you. From the POV of XML Graphics Commons we have a problem. We've voted on the plan for Commons where we said that we'd try to remove the dependency on Commons Logging. If there is a problem with that, the right place to raise this is [EMAIL PROTECTED] On 05.09.2005 21:15:50 Simon Pepping wrote: snip/ I am not sure that I understand everything that is being said here. But I am alarmed when I hear that basic libraries, in this case the FontServer, shouldn't log anymore. In my experience a font system requires powerful logging, in order to expose runtime behaviour to the systems manager or end user. Configuring font systems and understanding why a piece of font software does not use it as you expect, is a hard task that requires suitable runtime information from the software. Jeremias Maerki
RE: Logging for FOrayFont
J.Pietschmann wrote: /me ducks. Hehe. I've also thought again that designing certain interfaces (and piling them on each other) must be really really fun. Your meaning here is, at best, ambiguous. Please clarify. Victor Mote
Re: Logging for FOrayFont
I'm sorry but I've got to stop here. No energy left for this discussion. I didn't manage to get my meaning across and so we're talking about different things. I'll try to look into aXSL and FOray later and see if I can create a patch to demonstrate what I was talking about. Sorry for wasting your time. This was really not directed at you but rather at the FOP team so they know we have a potential problem when moving code over to Commons. It wasn't supposed to extend into such a discussion. I'm anxious to see what happens when I actually start to migrate code to Commons On 05.09.2005 22:29:46 Victor Mote wrote: Jeremias Maerki wrote: A PseudoLogger is required (but can be passed null) in the FontServer constructor That's an implementation detail and not a problem. It has nothing to do with the API. FontServer is an interface in the API and you are talking about the implementation of FontServer here, I assume. Well, it may have nothing to do with the aXSL API, but it certainly has something to do with the FOray API. To implement FOray (which I understand to be the discussion), you have to do both. If it is wrong to demand a logging mechanism in aXSL's API, how can it then be right to do so in FOray's API? It sounds like I could solve all of your concerns by creating a FOray FontConsumer implementation that is an abstract class, making you pick some class to extend it, and then simply demanding a logging mechanism in the implementation's constructor. Am I right? If so, doesn't it all seem silly? The client application now has to have implementation-specific code embedded at FontConsumer (document) construction. Poof. Pluggability just disappeared. For what benefit? None. Your client application still supplies exactly the same thing it supplied the other way. Really, why does FOP care whether it needs to supply logging information because aXSL requires it or because FOray requires it? and is required in a method in FontConsumer. But FontConsumer is implemented on the client side, in which the client application tells FOray about itself. This method getPseudoLogger() is what caught my purist's eye in the first place. It breaks IoC. I don't care. (I am sure that comes across more rudely than I intend). There are more important things here. Second, why should FOray limit its clients to only use static logging? If the client has to expose a static logging mechanism to FOray in order to get static logging to work, what can possibly be wrong with exposing a non-static logging mechanism to FOray? Right now, FOray doesn't care whether static or non-static logging is used. Why should it? Exactly. Why should it? If you remove all logging concerns from the work interface you don't do any assumptions about how logging is done. The presence of getPseudoLogger(), though, produces a strong emphasis on non-static logging. Not true. Your PseudoLogger implementation can use whatever logging it wants to, or, as may please you better, send it to /dev/null. Again, if you accept implementation constructors as part of the API that FOP must deal with, then I think your whole line of reasoning disappears here. Third, lets define the concern. importantMy understanding of Separation of Concerns in this case is that FOrayFont owns the concern that a message needs to be logged, and that the client application owns the concern of how that logging should be accomplished./important In order to maintain that Separation of Concerns, one of two things must happen: 1. The client must tell the component how stuff should be logged. 2. The server must tell the client what should be logged. This means some logging-related stuff will appear in the interface between the two. Not IMO. It can be an implementation detail. See more below. The design considerations are as follows: 1. FOrayFont needs to be able to log messages. For whom? For the developer or for the end-user? Because Ah, now this is what I consider to be an implementation detail! that's what I've learned during the past months: That it should be well divided between the two audiences. The speciality is that the developer doesn't need a logger per processing run (i.e. non-static logging) and the end-user often needs more than just pure Strings through a generic logging interface. Note that this is not yet reality in FOP but I believe it will be soon. Well, I noticed that you chose to ignore the important tag, and it shows up here. Why should the component concern itself with the differences between the two audiences? If a user wants to log debug or trace messages into a permanent file somewhere, what business is that of FOrayFont's All it should do is respond to the level of detail that is requested by the client application, and to place it where the
Re: Logging for FOrayFont
Victor Mote wrote: Your meaning here is, at best, ambiguous. Please clarify. If you've looked into a fair number of open source projects, and add projects from your work environment, you'll probably see certain abstractions over and over again. Counting the number of reincarnations, logging certainly comes into the top ten, I guess even at position three after configuration services and i18n. The tendency to have a project specific abstraction, however small, isn't new, check out the history part in the syslogd docs. If you are interested in a list of other recurring themes beside the three named above: - service discovery, often including loading code or data from a directory or some other repository - URL resolving - URI, URL, pathname and search path handling as Strings - command line argument parsing, maybe as part or complement of a configuration service - object pooling, in particular network connection pooling and multiplexing - XML creation - Java object persistence The list isn't complete of course. J.Pietschmann
Re: Logging for FOrayFont
Victor Mote a écrit : Actually there is not a level named debug, although I might have defined that constant equal to finest in one of the earlier versions. This does not appear in CVS. I would suggest you to redefine such a constant to remove any ambiguity, as as you can see it confused me. Here is the way I mapped the Avalon levels in the AvalonLogger implementation: http://cvs.sourceforge.net/viewcvs.py/axsl/axsl/axsl-common/src/java/org/axs l/common/AvalonLogger.java?view=markup FINEST debug FINER info FINEinfo CONFIG info INFOinfo WARNING warn SEVERE error Why not. Is I know now that debug corresponds to finest I'll follow the same scheme for commons Log. I don't really feel strongly about it either, but perhaps a bit more strongly than you for the following reasons: 1. From a sheer standard aspect, I wanted to stay as close to the Java logging system as possible. I would have used the java.util.logging.Level instances (for type safety) instead of numeric constants, except for trying to retain Java 1.3 compatibility. 2. I prefer to allow for more granularity rather than less (within reason), even if we don't think we need it right now. 3. This is one of those things that you can change on Tuesday to make one party happy, then change back again on Wednesday to make another party happy, all for very little benefit. In short, there is no way to make everyone happy. I understand your concerns and agree with them. Also, I don't know if you noticed the following methods: info(String message) warn(String message) error(String message) debug(String message) which correspond directly to the Avalon methods of the same name, and are intended to provide a sort of mapping for them. Certainly, but I also have to map the logMessage method... I don't mind adding one more called trace(String message) if that would make the mapping concept more clear for you. Well, no need I think; as trace is below debug and debug is mapped to finest, there is no corresponding log level for trace. I'm satisfied with your explanations. Please just add a LEVEL_DEBUG constant and I'm OK with your interface. Regards, Vincent
Re: Logging for FOrayFont
Hi Victor, What I liked with the Avalon Logger is the one-to-one correspondance between it and Commons' Log; commons just has one more level which is trace. So writing a Logger adapter that delegates logs to a Log instance is trivial. Now it's different because PseudoLogger has 7 log levels + 1 debug level, whereas commons Log has 6 levels with different purposes. The best mapping that I see is the following: PseudoLogger - Log finest trace finer trace finetrace debug debug config info infoinfo warning warn severe error Log's fatal level wouldn't be used. Writing an adapter in the other way would have been somewhat easier (and BTW corresponds to commons' Jdk14Logger). Personally I tend to find Commons log levels more intuitive and useful than the Jdk ones: I don't really know what to do with 3 fine, finer, finest and one config levels. May I suggest you to use Commons' style of levels instead? That said, this is by no means dramatic. For me it's just a matter of writing another wrapper. I agree that it's a bit cleaner if the font system has its own logging rules, independently of other existing logging systems. So no problem for me. Vincent Victor Mote a écrit : I just completed a project to make FOray's logging a bit more flexible. It now logs from an interface called org.axsl.common.PseudoLogger. Logging levels are the same as those for java.util.logging.Level (in Java 1.4 and higher), except that integrals are used instead of Level instances. I also wrote an implementation org.axsl.common.AvalonLogger, which FOray uses (for now) when it needs to *create* a logger. Since all loggers in the font system are supplied to the font system (instead of created within it), FOP should simply pass a different implementation to keep its logging consistent within itself. The AvalonLogger is a thin wrapper around an, er, Avalon ConsoleLogger, and is essentially an Adapter between the Avalon logging system and PseudoLogger. A similar approach can be used with whatever logging system FOP decides it wants to use. Writing the adapter should be fairly trivial, and it should be possible to use any logging system with this approach. I hope this makes the integration work a bit easier and the results more satisfactory to FOP. Please let me know if you have questions. Victor Mote
RE: Logging for FOrayFont
Vincent Hennebert wrote: What I liked with the Avalon Logger is the one-to-one correspondance between it and Commons' Log; commons just has one more level which is trace. So writing a Logger adapter that delegates logs to a Log instance is trivial. Now it's different because PseudoLogger has 7 log levels + 1 debug level, whereas commons Log has 6 levels with different purposes. The best mapping that I see is the following: PseudoLogger - Log finest trace finer trace finetrace debug debug config info infoinfo warning warn severe error Actually there is not a level named debug, although I might have defined that constant equal to finest in one of the earlier versions. Here is the way I mapped the Avalon levels in the AvalonLogger implementation: http://cvs.sourceforge.net/viewcvs.py/axsl/axsl/axsl-common/src/java/org/axs l/common/AvalonLogger.java?view=markup FINEST debug FINER info FINEinfo CONFIG info INFOinfo WARNING warn SEVERE error Log's fatal level wouldn't be used. Writing an adapter in the other way would have been somewhat easier (and BTW corresponds to commons' Jdk14Logger). Personally I tend to find Commons log levels more intuitive and useful than the Jdk ones: I don't really know what to do with 3 fine, finer, finest and one config levels. May I suggest you to use Commons' style of levels instead? That said, this is by no means dramatic. For me it's just a matter of writing another wrapper. I don't really feel strongly about it either, but perhaps a bit more strongly than you for the following reasons: 1. From a sheer standard aspect, I wanted to stay as close to the Java logging system as possible. I would have used the java.util.logging.Level instances (for type safety) instead of numeric constants, except for trying to retain Java 1.3 compatibility. 2. I prefer to allow for more granularity rather than less (within reason), even if we don't think we need it right now. 3. This is one of those things that you can change on Tuesday to make one party happy, then change back again on Wednesday to make another party happy, all for very little benefit. In short, there is no way to make everyone happy. Also, I don't know if you noticed the following methods: info(String message) warn(String message) error(String message) debug(String message) which correspond directly to the Avalon methods of the same name, and are intended to provide a sort of mapping for them. I don't mind adding one more called trace(String message) if that would make the mapping concept more clear for you. In short, it isn't a big deal to me either, but I would prefer to leave it alone unless there is some compelling reason to change. When you say somewhat easier, we're talking about a pretty trivial difference, right? Probably just 7 case statements instead of 5? If not, I will be glad to rethink this. I agree that it's a bit cleaner if the font system has its own logging rules, independently of other existing logging systems. So no problem for me. Yes, I thought this was pretty nice. The other thing it allowed me to do is to make the FOray logging system very generic. I use the PseudoLogger interface everywhere. When I need to instantiate a logger, I can use a static method to do that. This means that I could switch over to a new logging system for the price of changing the static method and writing a new wrapper/adapter that implements PseudoLogger. Victor Mote
