At 15:51 11.07.2002 -0700, Mark Womack wrote:
> > That's an interesting idea. It preserves backward compatibility but
> > has the disadvantage condemning existing services to poor performance.
>
>We could release just the new appender as a patch to older log4j instances
>so they could use it if they wanted to (they would have to upgrade to use
>the new Receiver stuff). Others could just upgrade their configurations to
>use the new appender/receiver. I think that is more appealing than breaking
>something as fundamental as LoggingEvent.
>
>But, in thinking about it some more...how can we put the LoggingEvent
>together on the receiving side? Aren't many of the data members we will
>want to pass across the socket private or otherwise inaccessible? That
>would make it a challenge.
The only solution I can see is for this appender to get the
LoggingEvent, read its fields, transmit them on the wire, and have the
receiver reconstruct a new LoggingEvent. The reconstruction is the
iffy part... some would say the challenging part. :-)
> > >This does not address the request to add more info to the
> > LoggingEvent, like
> > >the ip address of the machine the event originated from.
> >
> > Oh, right. How about just using the MDC, as in MDC.put("ip",
> > "128.178.45.4")
> > on the client and retrieving it with MDC.get("ip") on the receiver
> > side? Wouldn't that work?
>
>Yeah, that would work. If we did this automatically in the appender then it
>only gets set if the event is shipped across to a remote server. Maybe we
>could make it something like "log4j.originating_ip" to avoid clashes with
>keys developers use for their own data. Viewers like Chainsaw and LF5 could
>look for this MDC key and use it to filter if it exists in the event.
Good point. How about the shorter "log4j:oip" ?
>-Mark
--
Ceki
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
