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]
