Mark, Should I build the basic app, and then submit it to sandbox, or start building it there from the get-go?
Richard On Tue, 2003-02-11 at 14:38, Mark Womack wrote: > I'd like to see a tool that performs reflection on the various classes to > let you know what parameters can be set. So, if I chose to add a > FileAppender, the list of configuration options would be gathered by looking > at the property setter methods defined in that class. > > I remember someone mentioning a configuration tool for log4j a very long > time ago, but I don't remember the details. I think that a tool like this > would be very cool. You should consider placing it into the log4j-sandbox. > > -Mark > > > -----Original Message----- > > From: Richard Bair [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, February 11, 2003 9:59 AM > > To: Log4J Developers List > > Subject: Configuration GUI > > > > > > Hey Folks, > > > > I'm gearing up to write a preliminary gui for editing log4j > > configuration files. I don't know of any that currently exist(?). My > > employer has need of a simple configuration gui (it won't be very > > flexible in this first version). After writing that, I'll be more > > familiar with the issues involved and will start tackling a > > more generic > > setup on my own time. > > > > Initially I was planning on using DOM for parsing and modifying XML > > config files. It seemed a natural fit. However, in the spirit of > > logging.apache.org, and because one of our requirements at > > work is that > > our app work for all of the log4j variants (perl and c++ in > > particular), > > it looks like we'll have to use standard properties files. > > > > I'm wondering if anybody out there: > > > > 1) Has tried to build one of these before and has any ideas > > 2) Knows of code that would be a good fit for parsing and saving the > > properties files (log4j obviously has code for parsing the properties > > file, but I don't know if it will be applicable or need reworking) > > 3) Thinks this is a bad idea ;-) > > > > Ideally, we'd be able to provide plugin functionality so that > > no matter > > what configuration file style users prefer, we'd be able to read/write > > them. > > > > Thoughts? > > Richard > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]