> I thought I'd just through out there a little status update. > I've written > the bulk of the "rough draft" of the configuration gui guts. > I'm working > on the windows right now. Unfortunately, my work situation is > deteriorating rapidly, which is occupying a tremendous amount > of my time. > I hope that tonight I can finish the rough draft and upload > it tomorrow. > I'll be able to get back to it in about a month (maybe less if > circumstances become favorable - here's hoping).
Work Smork, and those pesky bills-to-pay. :-) > For any appender that we discover on the classpath (how > should this be > done - config xml file?), we will look for a corrosponding class > XXXConfigPanel that implements the ConfigPanel interface. I haven't > worked out the specifics for the search, but it would be > something like: > 1) Look in the same package as the Appender for its corrosponding > XXXConfigPanel (where XXX is the name of the Appender class, such as > ConsoleAppender) > 2) Look in a config file to see if it is specified elsewhere > 3) Use the DefaultConfigPanel > > Maybe switch 1 & 2? How should I determine what appenders > are availiable? > Of course, we can hard-code the default log4j appenders in > the lookup > code, but maybe we should rely on a config file instead. Thoughts? I think we should look at using the commons-discovery package. You can use it to search for classes that implement a given class/interface. I looked at the current version, and it did not seem to have an interface for getting back a list of classes that implement a given interface (it only returned the first one it could instantiate), but the underlying code could be used to do it. Anyway, it is worth a look. But just going with a config file to start is fine. This is something that can evolve. > Also, I wanted to provide a Factory for parsing/creating > config files. The > gui should be able to set and alter values for various > Destinations/Loggers irrespective of the underlying config > file storage > mechanism (db, xml, flat file, ldap, whatever!). So a > factory would be > developed for each type of config "file" out there - > following whatever > semantics it needs too. Thus, if the log4perl config file is > not exactly > the same as the log4j property config file, then a new > factory could be > created by the log4perl guys that would parse/save the > settings to their > particular format. > > Also, since I've placed the core logic for configuration in > the AcornPanel > and associated classes, it is possible to embed this panel in > a dialog or > frame or applet. Handy. The core logic is (or should be) > separated from > the gui itself, of course, so that someone could create an > HTML front end > if they wanted too. It sounds like a good start to me. This tool is a definite sandbox contender. -Mark --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
