> 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.
> >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.
-Mark
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
