--- robert burrell donkin <[EMAIL PROTECTED]> wrote: > > On Monday, May 13, 2002, at 10:57 PM, Ceki G�lc� > wrote: > > > 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. > > my main worry from a technical point of view would > be about beanutils. you' > ll find it very difficult to decouple digester from > beanutils and have > anything let that's viable. i'm pretty confident > that the core digester > stuff is pretty well debugged - but i do have > worries about beanutils.
First, log4j does not need to implement all the Rules that digester-commons has. Second, we can implement rules for setting properties, i.e SetPropertyRule, with our *existing* capability to set parameters. As for SetPropertiesRule (note the plural) it would be nice to have but certainly not crucial. > in terms of maintainability, it all depends on how > you do it. > > obviously you'd need to repackage digester and > beanutils, and you'd want > to drop any unused classes. one way that you could > reduce maintenance to a > minimum would be to create classes with the same > signatures as the > interface and class that digester relies upon from > commons-logging and > then just substitute the names in the import. > - robert I have been studying the digester code quite carefully. My conclusion is that as long we do not try to be fancy and if our clone will be for log4j "internal" use only, then we can make many simplifications. It will be an interesting excercise but without glory whatsoever. __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
