Hey Ceki,

>I'd switch 2 and 1.
>
>Rationale: Explicit directives by the user should override implicit 
rules.

Doh!  Of course - switching 1 and 2 :-$


>However, if the DefaultConfigPanel is powerful enough, then there may be 
no 
>need for explicit ConfigPanels per appender.

I wanted to provide explicit ConfigPanels per appender primarily to 
provide a mechanism for 3rd party/propriety code to provide a custom, 
pretty gui.  I've also found that generic gui's are usually harder for end 
user's to understand and use than a specific gui.  That's my target group 
here - the average Joe out there who wants to set up logs for some app he 
bought/downloaded.

I did have another question that has some bearing on the 
DefaultConfigPanel - how does log4j determine what properties can be set 
via the config files?  Is it all based on generic reflection?  Where is 
the code at that does this work?

Thanks!
Richard





Ceki Gülcü <[EMAIL PROTECTED]>
03/24/2003 11:34 AM
Please respond to "Log4J Developers List"
 
        To:     "Log4J Developers List" <[EMAIL PROTECTED]>, 
"Log4J Developers List" <[EMAIL PROTECTED]>
        cc: 
        Subject:        Re: Configuration GUI Status


Hi Richard,

Here are my (very) quick comments.

At 11:11 AM 3/24/2003 -0700, [EMAIL PROTECTED] wrote:
>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?),

The list of appenders to offer to the client for configuration can be 
based 
on a config file specific to the Configuration GUI. If there is a new 
appender, we just add it to the list.

>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'd switch 2 and 1.

Rationale: Explicit directives by the user should override implicit rules.

However, if the DefaultConfigPanel is powerful enough, then there may be 
no 
need for explicit ConfigPanels per appender.

>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.

Sounds brilliant to me.

>Thoughts?
>
>Richard

--
Ceki 


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Reply via email to