RE: Logging for FOrayFont
Hi Joerg: > Victor Mote wrote: > > OK. Still I miss your point. > > Well, I think loggin is much overrated and it is really > overdone in FOP. I agree. Some of that is a function of being alpha-quality code. As people get more comfortable that something actually does work, you are right that a lot of the logging can be removed. The communal nature of open source and the transient nature of the pool of people working on various pieces of code contributes to the problem as well. If you have to wade through a lot of logging code to get anything done, you are more likely to yank it out than if you ... never actually look at it again. As far as users go, some folks like a lot of logging, others like less or none. High-volume batch users generally want more, interactive users want less. Not every interesting thing that happens warrants throwing an exception. I have been working on font-selection today, and some users might be interested to know or even record on a permanent basis that their first-choice of font-family was not used. > 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: ... I agree. > 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. I generally agree, although I seem to like logging better than you or Jeremias. This could be a cultural legacy from my one-compile-per-day, the-lineprinter-is-your-debugger days. And perhaps I'll be more in agreement after I understand the alternatives better. Anyway, thanks for making your point more clear. Victor Mote
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: min>max, 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
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
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: > > > 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
J.Pietschmann wrote: > 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. OK. Still I miss your point. It could be any one of the following: 1. You are arguing against the "no external dependencies" idea. 2. You support the "no external dependencies" idea, and find it humorous when someone has to reinvent the wheel to comply with it. 3. You support the "no external dependencies" idea, and think that there was some more elegant solution that FOray should have implemented. 4. You agree with Jeremias that there is no need for logging information to pass through an interface between two subsystems. 5. You agree that logging for such a system is not necessary. The list isn't complete of course. Victor Mote
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
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". My 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. > > > > > > 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 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 t
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
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". My 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. > > > > 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 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 client application wants, both of which, AFAICT, you won't allow me to find out. > > 2. FOrayFont needs to be able to work with any client system, > > regardless of their preferences on logging. > > Nobody challenges that. Due to input from Batik the question > is raised whether such a library should do any logging at > all. Don't get me wrong. If you don't want to do any logging, send the log messages to /dev/null. But it is not reasonable to insist that other client applications must effectively do the same thing by never getting the opportunity to log. > I'm all for developer-oriented logging, even in basic > libraries. It's just that I somehow need
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: > 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
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
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
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". My 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. > > 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 S
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
Vincent Hennebert wrote: > 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/o > > rg/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. 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 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. 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. > 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? A PseudoLogger is required (but can be passed null) in the FontServer constructor 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. 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? Third, lets define the "concern". My 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. 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. The design considerations are as follows: 1. FOrayFont needs to be able to log messages. 2. FOrayFont needs to be able to work with any client system, regardless of their preferences on logging. I can keep all logging internal to the FOrayFont subsystem, which would mean that the client application (FOP) has no control over the logging whatsoever. Very bad. FOray has to guess what kind of logger to use, and it will never be right. I can expose a logging interface that allows the client application to handle logging its own way. This has been the approach used so far. The only other solution is a bit more complex, and IMO, quickly becomes ugly. FOrayFont currently asks some client object to implement the FontConsumer interface. Instead of having FontConsumer provide a PseudoLogger, it could have a method instead that logs messages: /** * @param level An integer describing the level at which this message should be logged, * that is, error, warning, debug, etc. */ public void logMessage(String message, int level) ; The problem here is that I need to then create another interface that has something similar that can pass itself to FontServer so that general (not document-specific) logging messages can be handled. I also need to create one for Graphics, Text, FOTree, etc. I will have 10 or 12 methods in various interfaces that all do the same thing. This seems silly to me. This begs for a type to do this, which the Avalon Logger interface provided and which PseudoLogger provides as well. Further, does a logMessage() method still expose logging functi
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. Chris
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
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
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
