RE: Reproducing the Apache license

Enclosed is an attempt to configure Jalopy to insert the fulle Apache 1.1 license at the top of the file. It inserts it at the top of the file, but it does not remove the old header first. Plus, it seems to just keep re-inserting the header everytime I run Jalopy. The Jalopy documentation seems

Re: New Chainsaw features - feedback?

Vow! More comments below. At 09:56 PM 2/23/2003 -0800, you wrote: I've spent some time working on enhancements to the Chainsaw UI and I thought I'd step back and see what people think. Here's what I've implemented so far: If there are any suggestions for improvement/changes/duplication of effo

Re: [ChainSaw] internal TableModel size & memory considerations

At 02:09 PM 2/25/2003 +1100, Paul Smith wrote: I think I read somewhere that LogFactor5 can place a bounds on the # of events that can be held in the internal structures to prevent Memory hogging (I may be wrong). I can't see that ChainSaw has this feature. This is the feature that I tend to care

RE: Receiver Example (was: [ChainSaw] internal TableModel size & memory considerations)

> > The configuration for the event "sink": > > > > > > > > > > http://jakarta.apache.org/log4j/"; > > debug="true"> > > > > > > > > > > > > > > > > > value="%d{ABSOLUTE} %c: %m%n"/> > > > > > > > > > class="org.apache.log4j.net

RE: [ChainSaw] internal TableModel size & memory considerations

> class="org.apache.log4j.net.SocketReceiver"> > > Sorry, no need to reply, just browsing the SocketReceiver and Plugin architecture, and it makes sense now. The SocketReceiver plugin is reposting the received event to the local repository. Hence a (to be coded) local ChainSaw

RE: [ChainSaw] internal TableModel size & memory considerations

> I probably should have mentioned that SocketReceiver, > SocketHubReceiver, and > JMSReceiver are all currently implemented and available in > the cvs. I probably should have checked .. :) > The configuration for the event "sink": > > > > > http://jakarta.apache.org/log4j/"; > debug="true"

RE: [ChainSaw] internal TableModel size & memory considerations

> > That's a good refactor of the concept of the internal > Processor object, > > would make TableModel code lighter weight, encapsulate the > updating of the > > model into a separate class. > > agree - and this is good. Thx Oliver, you probably know the state of where the patches are at, woul

RE: [ChainSaw] internal TableModel size & memory considerations

Quoting Paul Smith <[EMAIL PROTECTED]>: > > It's not so wacky. For log4j v1.3 I am adding "receivers". > > Receivers are > > the opposite of appenders in that they can be configured to "receive" > > remote/eternal events. They can be configured as part of a logger > > repository, same as logge

RE: [ChainSaw] internal TableModel size & memory considerations

Paul Smith wrote: > > v1.3 is > > going to have a > > SocketReceiver (matching SocketAppender), SocketHubReceiver (matching > > SocketHubAppender), JMSReceiver (matching JMSAppender), and > > maybe more as > > makes sense. > > That's very much what I was thinking, but I hadn't thought about the eve

RE: [ChainSaw] internal TableModel size & memory considerations

> It's not so wacky. For log4j v1.3 I am adding "receivers". > Receivers are > the opposite of appenders in that they can be configured to "receive" > remote/eternal events. They can be configured as part of a logger > repository, same as loggers and appenders. Once the receiver > has an even

RE: Configuration GUI & logging.apache.org

Richard, I don't entirely agree with your assessment. If you have a tool that is working with current log4j, even if it only outputs property files, then please submit it for the sandbox. It may drive some of the thinking and convergence of the various logging packages. -Mark > -Original M

RE: [ChainSaw] internal TableModel size & memory considerations

Paul Smith wrote: > Another wacky concept might also be to have an option for a > ChainSaw window > to be able to define it's own Appender to write events being received to > some other local Appender (sort of Daisy chain ChainSaw to forward to a > local log4J system..) This way a remote server co

[ChainSaw] internal TableModel size & memory considerations

I think I read somewhere that LogFactor5 can place a bounds on the # of events that can be held in the internal structures to prevent Memory hogging (I may be wrong). I can't see that ChainSaw has this feature. There's a couple of ideas here: * Allow the definition of a limit via configuration,

RE: New Chainsaw features - feedback?

Oh, I forgot to ask, where can I try out the changes you've made? I'm itching to take a peek and try it out during the current app I am developing. cheers, Paul Smith - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional c

RE: New Chainsaw features - feedback?

Dang, somebody has been hard at work! Can't wait to see a new version. Richard On Mon, 2003-02-24 at 16:50, Scott Deboy wrote: > How about this: > > Add the ability to 'undock' a tabbed pane (and apply normal window > functionality - tile/cascade etc). > > Add the ability to 'clone' a tabbed pa

RE: New Chainsaw features - feedback?

> Add the ability to 'undock' a tabbed pane (and apply normal window > functionality - tile/cascade etc). another good idea. It's really hard to guess what the users want. Some may want to have multiple Windows instead of 1 window with multiple docs. Maybe we could allow both, like how MS Office

RE: New Chainsaw features - feedback?

How about this: Add the ability to 'undock' a tabbed pane (and apply normal window functionality - tile/cascade etc). Add the ability to 'clone' a tabbed pane. LoggingEvents would be sent to both tabbed panes and filtered/colorized independently. This relates back to my earlier idea of being

RE: New Chainsaw features - feedback?

[Notes 1-2 all good stuff IMHO ] > 3: Tabbed pane support - a tabbed pane for each unique > machinename/app combination. I thought about allowing the > user to pick which fields are used to build the unique tabbed > panes, but I'm not sure how useful it would be. I could see > using the NDC

DO NOT REPLY [Bug 17341] - Chainsaw color coding

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 17341] New: - Chainsaw color coding

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 17331] - SocketAppender throws a full stacktrace during initialization

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Re: New Chainsaw features - feedback?

Scott Deboy wrote: I've spent some time working on enhancements to the Chainsaw UI and I thought I'd step back and see what people think. Here's what I've implemented so far: If there are any suggestions for improvement/changes/duplication of effort in what you see here, please let me know. 1: L

DO NOT REPLY [Bug 17331] New: - SocketAppender throws a full stacktrace during initialization

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu