LOL! I think we just answered each others questions. :-) > -----Original Message----- > From: Mark Womack [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, 12 February 2003 10:36 > To: 'Log4J Developers List' > Subject: RE: Configuration GUI > > > [EMAIL PROTECTED] - > http://archives.apache.org/eyebrowse/SummarizeList?listId=19 > > [EMAIL PROTECTED] - > http://archives.apache.org/eyebrowse/SummarizeList?listId=135 > > As Oliver has said, it is likely that LGPL code will not be allowed, > especially if used at compile time (referenced as an import). I believe > that not allowing LGPL is already Apache policy, so some of the jakarta > projects have to come into compliance with this. > > But we can still use Checkstyle and Jalopy, can't we? We use > them as tools, > not as part of the library. And we don't release them with > log4j or include > them in the cvs. My understanding is that this is kosher, but I haven't > been able to read all the emails. I hope the ASF board and the > Jakarta PMC > release some kind of document when this is all said and done. Otherwise > we'll be having this discussion again in three months time. > > -Mark > > > -----Original Message----- > > From: Richard Bair [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, February 11, 2003 3:24 PM > > To: Log4J Developers List > > Subject: RE: Configuration GUI > > > > > > 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] > > > > --------------------------------------------------------------------- > 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]
