Hey Oliver, thanks for the info. I agree.
I'll be happy to provide patches in stages. The features I listed first in my email are the ones I haven't started yet. I have written a UDPReceiver that accepts data via a UDPAppender defined with an XMLLayout pointing to a multicast address. The data is rendered via TableModels in tabbed panes, one for each client. So, multi-client support is here, and will be easy to use once the dtd and XMLLayout are updated to support properties as in the latest LoggingEvent. I'll just define a custom property and have the UDPAppender set the machine name as that property value. If there is some other 'identifier' provided, I'll create a new tabbed pane showing this combined value as the tabbed pane name (example: scott1.client and scott1.server) - allows me to run multiple apps from the same machine and have them show up in separate panes. I'll also add disabling on event reception on a per-tabpane basis. I need to integrate this with Chainsaw, which obviously isn't tabpane-based nor supportive of LoggingEvents received as XML, but I think the refactoring should go relatively smoothly. I was thinking I'd look into using the jakarta regexp package. If you have any suggestions at all feel free to shoot me a msg. Thanks, Scott -----Original Message----- From: Oliver Burn [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 18, 2003 1:23 PM To: Log4J Developers List Subject: RE: Chainsaw improvement question - support for multiple sources Scott, The changes you have/are making sound great. It would make sense if you could make the contributions in stages, rather than in one big hit. The advantage of stages are: - It allows for earlier feedback on code style and direction - The benefit of the changes made so far are able to be used sooner - It keeps the patch sizes down to make the process of inclusion quicker - It allows other people who are working on Chainsaw to see what changes have been made to avoid duplication of effort. BTW - what library are you using for the regular expression matching? Cheers, Oliver > -----Original Message----- > From: Mark Womack [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, 19 February 2003 05:25 > To: 'Log4J Developers List' > Subject: RE: Chainsaw improvement question - support for multiple > sources > > > Scott, > > First, I want to say that any changes you want to implement for > Chainsaw will be appreciated and reviewed for inclusion. We all love > Chainsaw around > here...:-) (and LF5 too...:-). > > Second, we have been kicking around the idea of having Chainsaw > support "gui plugins" where each plugin configures a source of logging > events. That way, > developers could implement new "plugins", based on the generic interface, > and Chainsaw would be able to pick them up with no changes. So, if you > would like to spend some time making your code define and > implement such a > concept, that would be great. > > Third, your point of including the IP address in the logging event, > yes it has been discussed before. One suggestion was to have the > remote appenders > place the info in the logging event prior to transmission under > a known MDC > key. Then the receiver could look for and use this key value. > But it just > occurred to me, can't the source be retrieved on the client side > by querying > the socket for the host/port information? And the source info > may be source > specific. For example, JMS messages may not make sense to have an ip > address, but instead the jms topic the event was received on. > It may make > much more sense for the client to get this information. It may also make > sense for the new Receivers in v1.3 to put this information > somewhere in the > logging event. > > -Mark > > > -----Original Message----- > > From: Scott Deboy [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, February 18, 2003 10:04 AM > > To: Log4J Developers List > > Subject: Chainsaw improvement question - support for multiple > > sources > > > > > > I am tinkering with some enhancements to Chainsaw that I hope will > > be accepted as part of the app when I'm done. > > > > I'm adding regexp-based filtering, saved settings, colorizing > > filters and some other stuff. No problem so far. > > > > I'm also adding multicast support for LoggingEvents broadcast using > > XMLLayout and UDPAppender. > > > > Here's my problem: I want to be able to differentiate between > > different LoggingEvent sources (different machines or different apps > > running on the same machine) in the UI (I'm using a tabbedpane). > > > > However, I don't see a 'source identifier' in the LoggingEvent (or > > DTD). Am I missing something? > > > > I can get the IP address/name of the source machine but where would > > it go in the XML? I suppose I could use a MDC to store the IP > > address/custom identifier, if it were supported in the DTD, but it > > seems overkill to have to define a MDC for both the machine name > > and custom id > > on each thread when these are machine-wide (or application-wide) > > settings. > > > > Is there some architectural changes to log4j in the pipe that will > > provide this functionality or make adding these identifiers easier? > > > > I've got differentiation working right now using NDC but it's a pain > > to have to place the machine name in the NDC for every thread. > > > > Is there a better way or am I reinventing the wheel? > > > > Thanks, > > Scott > > > > -------------------------------------------------------------------- > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
