We have previously discussed modifying SocketAppender, SocketHubAppender, etc to set a known MDC key to the hostname/hostip in the LoggingEvent before shipping the event to the remote receiver. That would not be a very big change and would require no changes to LoggingEvent or even the PatternLayout. Just use the MDC pattern using known key name. And we could make it so that the inclusion of the MDC is configurable on the appender, similar to how LocationInfo is handled today.
I do agree that hostname/hostip is one of those fundamental information bits when logging remote events. Especially if you are using a tool like Chainsaw/LF5, receiving events from different points of origin. It would be primo to allow filtering based on hostname/hostip. -Mark > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Thursday, December 12, 2002 2:52 PM > To: Log4J Developers List > Subject: RE: Hostname support in PatternLayout (patch included) > > > > > Thanks for the clarification. > > Originally, I had the Layout retrieve the hostname, but since logging > events can change machines and I want to record where they > came from, I > have to modify LoggingEvent. I have to record the hostname > somewhere before > it gets sent over a SocketAppender, and that must be in the > LoggingEvent. > > And then, I'm very wary of extending LoggingEvent cuz it's called > everywhere. I'll break everything. Thus, the only way to do this is to > either get the patch applied or use the MDC. I can use the > MDC. Properties > would work too, but stickiness is obviously better. > > And, yeah, not all machines have a hostname. A co-worker was > also wondering > if they could have more than one, if they have multiple > interfaces in some > complex corporate setting where they have one name from the > outside and > another from the inside. I don't know. > > dan > > > > > > Ceki Gülcü <[EMAIL PROTECTED]> on 12/12/2002 05:44:10 PM > > Please respond to "Log4J Developers List" > <[EMAIL PROTECTED]> > > To: "Log4J Developers List" <[EMAIL PROTECTED]> > cc: > > Subject: RE: Hostname support in PatternLayout (patch included) > > > At 17:14 12.12.2002 -0500, you wrote: > > > >Sorry. I'm not familiar with JMS. This notion of properties > just looks > like > >the MDC to me (and that's exactly how I would handle > hostname if it wasn't > >natively supported). Is there some other difference? I don't know how > these > >"properties" work exactly, but I don't want to have to set > them at each > >logging call. > > Very good question. The MDC and the properties field are very similar > but not quite the same. The MDC is sticky, in the sense that it is > enough to set a key once in the MDC for the lifetime of a thread. On > the other hand, a property in the properties field has to be set for > each and every logging event. An appender could very easily > do this at a > negligible performance cost (really!). > > >The MDC will work for me, I think. It's just sub-optimal to have > >applications set their hostname when they start up, cuz I still think > >hostname is fundamental enough to be supported. > > I concede that the hostname case is border line. Adding a hostname > field could work fine. > > > Note that from the user point there is not much difference between > calling event.setHostname(x) and event.setProperty("hostname", x). > > The real question is whether the hostname is set within the > LoggingEvent class or within an appender. I would prefer to do it in > SocketAppender or JMSAppender where the information is certain to be > useful rather than for all cases (in LoggingEvent) where usefulness is > uncertain. > > Also, not all machines have a hostname. > > >dan > > -- > Ceki > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> ---------------------------------------------------------------------------- --- This message and any included attachments are from Siemens Medical Solutions Health Services Corporation and are intended only for the addressee(s). The information contained herein may include trade secrets or privileged or otherwise confidential information. Unauthorized review, forwarding, printing, copying, distributing, or using such information is strictly prohibited and may be unlawful. If you received this message in error, or have reason to believe you are not authorized to receive it, please promptly delete this message and notify the sender by e-mail with a copy to [EMAIL PROTECTED] Thank you -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
