[accidently replied directly to Mark, sorry Mark..]
> - This is very much like the way LF5 works today, if I remember
> correctly.
> - Eventually I think we should allow multiple instances of
> ChainsawAppender,
> each with its own table model and its own instance of Main (or tab
> panel, in
> the future?) created via a Main(TableModel) constructor. This will
> allow
> one to configure specific loggers to output to specific
> ChainsawAppenders
> and thus specific Main windows, all in the configuration file. This is
> a
> step in that direction.
I like this approach, and +1(non-binding).
Playing devils advocate here, there is also the "reverse" of this model that
comes to mind. Thinking out loud here.. Where each configured
ChainsawAppender is purely the model in the MVC world. There could then be
another class (perhaps a Builder style pattern) that queries the Log4j
system to find any GUI-style Appender's (where ChainsawAppender is the first
one of this type, perhaps other styles later on). This builder could then
construct the relevant GUI window and bind the model (ChainsawAppender) to
it.
This example is probably totally over the top, but hopefully you can see the
flexibility.
<code-snippet>
...
Log4JGuiBuilder builder = new StandardChainsawGuiBuilder();
Collection guiAppenders = <queries Log4J for Appenders "tagged" for
GUI, this would be an extension to Log4J>
builder.build(guiAppenders);
...
public class StandardChainsawGuiBuilder
implements Log4JGuiBuilder {
...
public void build(Collection guiAppenders) {
for(Iterator i=guiAppenders.iterator(); i.hasNext() {
GUIAppender appender = (GUIAppender)i.next();
MainGUIWindow window = new MainGUIWindow(appender);
window.show();
/* @todo some mechanism for organising the windows
*/
}
...
}
</code-snippet>
I guess the goal that this approach solves is that the ChainsawAppender
doesn't know about it's visual representation. It's just a Sink for the
data. Then you can unload any GUI elements, and the (non-visual) Appender
keeps receiving events.
> - I modified the Start code so that if no configuration file is found, a
> default ChainsawAppender is created, attached to the root logger, and
> activated. This allows Chainsaw to still be used as a reader for
> offline
> xml files.
+1(non-binding) good move
> - I think that the Main class is now misnamed. I think it should become
> MainWindow or MainGUI. Something more descriptive to what it is being
> used
> for. We will still need to keep a deprecated version of Main around
> (that
> uses Start like today), but all the gui functionality gets moved to the
> new
> class.
Probably worth starting a new class, agreed.
>
> - You'll notice that in the case where no configuration file is
> specified I
> set the level of the "org.apache.log4j.chainsaw" logger to info. This
> is to
> avoid continuous output of debug statements by Chainsaw into the
> Chainsaw
> appender and window. If you look at Paul's config file, you'll see he
> sets
> the level to info as well.
:) Yeah, I was like "What the..." when I first started playing with Chainsaw
in Receiver mode and saw it displaying it's own logs, which generated it's
own logs, perpetually..
> (I could see us providing a
> singleton
> window to view them if needed).
That's a very good idea.
I'm all in favour of your patch anyway. Perhaps once we've seen Scott's
code it'll give us some concepts for next steps.
cheers,
Paul Smith
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
