That's good to know. Since I'm the sole author of the guibuilder code, I could easily alter the license any which way. I guess I'll have to look into the specifics of the differences between the Apache and LGPL Licenses. Is there a link to those discussions so I can read up on the differences? It may be that I want my guibuilder to use the Apache license too.
Richard On Tue, 2003-02-11 at 15:41, Oliver Burn wrote: > Richard, > > Be aware that there has been a lot of discussion within Jakarta/Apache > about the use of LGPL code on Jakarta projects. It seems to be > highly likely that it will not be allowed. > > Is this what the other committers believe the case is? > > I would hate to see you spend time going down a path of using LGPL > code, when the Log4J project may not be able to use it. > > Regards, > Oliver > > > -----Original Message----- > > From: Richard Bair [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, 12 February 2003 09:08 > > To: Log4J Developers List > > Subject: RE: Configuration GUI > > > > > > The cool thing about this idea is that we'd be able to set properties > > for any given appender without the need of a ton of custom code. I'm in > > the process of building a guibuilder right now as well, so reflection > > and property sheets are almost second nature ;-) > > > > The one drawback I see with going this route is that creating a really > > generic tool sometimes means that the user interface isn't as intuitive. > > > > For instance, I think it would make for a cleaner UI to provide the user > > of a FileAppender a checkbox for bufferedIO and Append, and a spinner > > control for the BufferSize (or maybe an editable combo box) rather than > > providing a table that would list each of the properties and would use a > > different editor depending on the datatype (like the property sheet in > > VB or the guibuilder I've been writing). > > > > But I don't know. Maybe a good property sheet using reflection would > > rock over all. I'd be able to reuse a lot of my other code (its > > LGPL'd), and it really WOULD provide for all different appenders. > > > > Incidently, I was using java 1.4 for its java.beans package and > > functionality. > > > > 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] > > > > > --------------------------------------------------------------------- > 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]
