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]
