At 14:23 13.05.2002 -0700, Mark Womack wrote: > > >1) I do think that having a "special" version of the > > digester is going to be > > >a long-term headache. > > > > The issue is more social than technical. Unless there is a > > good reason to > > do it, it's pretty uncool to rip off someone else's code. > > Fortunately, in this > > case the authors have been very kind to grant permission to > > use and modify > > their code which somewhat mitigates my/our guilt. > >Actually, I am not so worried about the social issues. I am more worried >about what happens when bug fixes are applied to the original digester code. >Are we going to spend time moving the latest changes over into the log4j >version? Or are we going to make sure the log4j version works for our needs >and "freeze" it, not making any changes to it unless absolutely required. >Maintaining this code long-term is more the issue I am talking about.
The core of the digester code, if you look at it carefully is actually surprisingly simple, at least in versions 1.0 and 1.1. I do not forsee any serious maintenance issues although one can only be sure after actually writing the code. > > >2) I did like the suggestion (in concept) of having the > > commons-logging > > >log4j related bits live in the log4j jar. I don't know if I > > have followed > > >all the implications of this, but I like the idea at the moment. > > >3) I also liked the idea that the commons-logging interfaces > > could be broken > > >out from the implementations. [snip] > > Relying on LogLog for internal logs is not particularly > > elegant. It was done > > because log4j appenders were not reentrant. (i.e. an appender calling > > doAppend while in doAppend). This is fortunately very easy to > > fix > > > > Making log4j reentrant has several advantages, > > > > 1) log4j internal logs can be controlled with the full > > flexibility of log4j, > > 2) log4j can rely on libraries that in turn rely on log4j. > > > > I believe that the second point will become quite important > > in the long > > run. > >I agree. By doing this though, the AppenderSkeleton class is not really a >"skeleton" anymore. It should be thought of as a required "base" class that >all appenders should descend from. At least it appears so to me. I think >this should be explicitly explained somewhere if it isn't already. Good point. >Another feature that might feed into the LogLog/appender discussion is >"configuration error reporting". If there is a problem when configuring >log4j, have some kind of mechanism in place to "record" this. Then the >client code could take some action. This seems to be an often requested >feature, and I can see the utility of it. I was thinking that it would not >be difficult to add an error listener mechanism on LogLog. Developers could >use a LogLog method to attach listeners which would be called when a >warn/error message was called on LogLog. What they do with it is up to them >(their actions would be very limited to be sure), but at least they could >throw a flag or send a message or something to indicate that configuration >did not go as planned. But, if we are thinking that LogLog will go away, >maybe there is a better log4j way to do this. Indeed, it would be useful if both PropertyConfigurator and DOMConfigurator should admitted error handlers as parameters. Do you see what I mean? >-Mark -- Ceki -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
