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).
A little note on the architecture and design; I've created an AcornPanel class which is the main gui for configuration. This panel contains a JList and a detail panel (set in a JScrollPane) - these are arranged in a master/detail relationship. In the JList are items I've called "Destinations" - end user speak for Appenders - and items called "Loggers" - end user speak for, er, Loggers. When a user selects any item in this list, then a panel associated with that item (for instance, a ConsoleAppenderConfigPanel) will be displayed in the detail portion of the AcornPanel allowing the user to configure settings for that item. Any Appender/Destination that does not have an associated ConfigPanel will display a DefaultConfigPanel. The DefaultConfigPanel uses reflection to determine which properties can be set on the Appender/Destination, and their datatype (thus dictating what editor should be displayed for the property). Properties and values in this default panel will be displayed in a customized JTable. 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? 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. Thoughts? Richard