> >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. > >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. > > To be honest, I don't see any value in moving around classes from > commons-logging > to log4j. - The log4j project could better define and refine the implementation to better match the current features of log4j. - It gives support to another jakarta project (commons-logging). - Gives credence to the idea that the logging interfaces should live in their own jar and implementations should live the the particular library/api they are meant for. > 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. 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. -Mark -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
