RE: Hostname support in PatternLayout (patch included)

[Greg Cutler]

Hello -

I'm following this thread 'cause I'm somewhat
interested in remote logging, but don't know my way
around the internals so well, so pardon any
ignorance...


> Is stickiness really better? The hostname could be
> looked up once and 
> subsequently remembered by the SocketAppender.
> Before sending a logging 
> event on the wire, the SocketAppender could set the
> hostname (which it 
> keeps in its memory). The cost is a method call plus
> a hash lookup followed 
> by a variable assignment, in other words "nada"
> compared to serialization.

Question here: if SocketAppender is the place where
the hostname is set, what happens if you chain
SocketAppenders. Event is generated on HostA, sent to
HostB & filtered, then forwarded on again to HostC.
Not saying this is a sensible setup, but would the
SocketAppender / stickiness interaction behave such
that the final destination still see HostA as the
event source, or would the host/ip get reassigned by
SocketAppender on the way out over the wire on HostB?

> >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.

We have quite a few machines in our productive
environment with multiple IPs, and multiple "apparent"
hostnames for different web server instances on the
same physical host.

Greg

__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Hostname support in PatternLayout (patch included)

[Niclas Hedhman]

On Friday 13 December 2002 01:52, Ceki Gülcü wrote:
> At 09:34 12.12.2002 -0800, you wrote:
> >Dan,
> >
> >My only concern is the changing of LoggingEvent.  This object gets
> >serialized across sockets from one log4j process to another, so
> > maintaining some level of compatibility between different log4j versions
> > is important. Won't adding a new private member break serialization
> > between versions? Anyone?
>
> No, adding fields does not break backward compatibility in the sense that
> clients version 'n' can send to server version 'n+1' where the difference
> between n and n+1 is the addition of an extra field. I don't remember what
> happens when n+1 sends to n.

Adding private members and maintaining compatibility in both directions is 
more or less automatic;

v1 -> v2,  the member field in v2 is filled with null for objects, false for 
boolean and 0 for numerics.

v2 -> v1, the member field is transferred but ignored by v1.


To allow for better v1->v2 handling, one should do explicit deserialization by 
readObject method;

private void readObject( ObjectInputStream in )
throws IOException, 
{
in.defaultReadObject(); //takes care of most
if( m_NewMember == null )
m_NewMember = "Not serialized."
}

kind of thing


Niclas

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Hostname support in PatternLayout (patch included)

[Ceki Gülcü]

At 17:52 12.12.2002 -0500, you wrote:



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.


Is stickiness really better? The hostname could be looked up once and 
subsequently remembered by the SocketAppender. Before sending a logging 
event on the wire, the SocketAppender could set the hostname (which it 
keeps in its memory). The cost is a method call plus a hash lookup followed 
by a variable assignment, in other words "nada" compared to serialization.

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



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Hostname support in PatternLayout (patch included)

[Mark Womack]

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]>

RE: Hostname support in PatternLayout (patch included)

[Daniel . Hannum]

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]>

RE: Hostname support in PatternLayout (patch included)

[Ceki Gülcü]

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:   
For additional commands, e-mail: 

RE: Hostname support in PatternLayout (patch included)

[Daniel . Hannum]

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.

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.

dan





Ceki Gülcü <[EMAIL PROTECTED]> on 12/12/2002 04:51:53 PM

Please respond to "Log4J Developers List" <[EMAIL PROTECTED]>

To:"Log4J Developers List" <[EMAIL PROTECTED]>
cc:

Subject:RE: Hostname support in PatternLayout (patch included)



I did not suggest that we use JMS but the properties as in JMS. Sorry,
apparently I was not very clear.

More concretely, we add a new field "properties" which is a hashtable
that carries any number of key-value pairs. Hostname becomes just a
particular key. Is that any clearer?

At 15:50 12.12.2002 -0500, [EMAIL PROTECTED] wrote:

>And JMS is a fine solution if you can use JMS. But if you aren't using
>J2EE, you can't use JMS. Running tomcat/apache as an app server lends
>itself to not knowing which host the message came from. Surely I'm not the
>only one with a central repository of logs coming from various hosts who
>can't use JMS?
>
>To me, hostname is simple and obvious. It's up there with thread name and
>class name as fundamental information to be present in a log. Username,
and
>session id are J2EE-specific concepts. Or more generally, they are
concepts
>that different app writers might interpret differently, and so they
>shouldn't be in some canonical list of things you can log. But hostname?
>Hostname is canonical. Everyone knows what it means, and everyone with a
>remote configuration needs to know it. Thus, I think log4j should support
>hostname retrieval natively.
>
>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]>

RE: Hostname support in PatternLayout (patch included)

[Ceki Gülcü]

I did not suggest that we use JMS but the properties as in JMS. Sorry,
apparently I was not very clear.

More concretely, we add a new field "properties" which is a hashtable
that carries any number of key-value pairs. Hostname becomes just a
particular key. Is that any clearer?

At 15:50 12.12.2002 -0500, [EMAIL PROTECTED] wrote:


And JMS is a fine solution if you can use JMS. But if you aren't using
J2EE, you can't use JMS. Running tomcat/apache as an app server lends
itself to not knowing which host the message came from. Surely I'm not the
only one with a central repository of logs coming from various hosts who
can't use JMS?

To me, hostname is simple and obvious. It's up there with thread name and
class name as fundamental information to be present in a log. Username, and
session id are J2EE-specific concepts. Or more generally, they are concepts
that different app writers might interpret differently, and so they
shouldn't be in some canonical list of things you can log. But hostname?
Hostname is canonical. Everyone knows what it means, and everyone with a
remote configuration needs to know it. Thus, I think log4j should support
hostname retrieval natively.

dan


--
Ceki



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Hostname support in PatternLayout (patch included)

[Daniel . Hannum]

And JMS is a fine solution if you can use JMS. But if you aren't using
J2EE, you can't use JMS. Running tomcat/apache as an app server lends
itself to not knowing which host the message came from. Surely I'm not the
only one with a central repository of logs coming from various hosts who
can't use JMS?

To me, hostname is simple and obvious. It's up there with thread name and
class name as fundamental information to be present in a log. Username, and
session id are J2EE-specific concepts. Or more generally, they are concepts
that different app writers might interpret differently, and so they
shouldn't be in some canonical list of things you can log. But hostname?
Hostname is canonical. Everyone knows what it means, and everyone with a
remote configuration needs to know it. Thus, I think log4j should support
hostname retrieval natively.

dan





Ceki Gülcü <[EMAIL PROTECTED]> on 12/12/2002 12:52:44 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 09:34 12.12.2002 -0800, you wrote:
>Dan,
>
>My only concern is the changing of LoggingEvent.  This object gets
>serialized across sockets from one log4j process to another, so
maintaining
>some level of compatibility between different log4j versions is important.
>Won't adding a new private member break serialization between versions?
>Anyone?

No, adding fields does not break backward compatibility in the sense that
clients version 'n' can send to server version 'n+1' where the difference
between n and n+1 is the addition of an extra field. I don't remember what
happens when n+1 sends to n.

>That being said, I do agree that this functionality is useful.  We have
>talked in the past about making changes in LoggingEvent that would make it
>incompatible with earlier versions, but much faster serialized and maybe
>more maintainable going forward.  Maybe v1.3 is the time to make the
change.

Why stop at hostname? What about username? Session id? Cookies? Address of
my dentist? You get the point. The JMS API solves this problem by having
properties attached to each message. See
http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/jms/Message.html


>-Mark
>
> > -Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, December 12, 2002 8:34 AM
> > To: [EMAIL PROTECTED]
> > Subject: Hostname support in PatternLayout (patch included)
> >
> >
> >
> >
> > Hi.
> >
> > I sent this patch in on Friday. It modifies PatternLayout so it can
output
> > the hostname via %h. It seems like it's simple enough for a developer
to
> > say good idea/bad idea, but it has slipped through the cracks.
> > Therefore, I
> > am submitting it again.
> >
> > Thanks
> >
> > Dan
> >
> >
> > diff -ru
> > orig/src/java/org/apache/log4j/helpers/PatternParser.java
> > src/java/org/apache/log4j/helpers/PatternParser.java
> > --- orig/src/java/org/apache/log4j/helpers/PatternParser.java
> > 2002-10-09 18:50:03.0 -0400
> > +++ src/java/org/apache/log4j/helpers/PatternParser.java
> > 2002-12-05 12:19:13.0 -0500
> > @@ -56,6 +56,7 @@
> >static final int LEVEL_CONVERTER = 2002;
> >static final int NDC_CONVERTER = 2003;
> >static final int MESSAGE_CONVERTER = 2004;
> > +  static final int HOSTNAME_CONVERTER = 2005;
> >
> >int state;
> >protected StringBuffer currentLiteral = new StringBuffer(32);
> > @@ -277,6 +278,12 @@
> >//formattingInfo.dump();
> >currentLiteral.setLength(0);
> >break;
> > +case 'h':
> > +  pc = new BasicPatternConverter(formattingInfo,
HOSTNAME_CONVERTER);
> > +  //LogLog.debug("Hostname converter.");
> > +  //formattingInfo.dump();
> > +  currentLiteral.setLength(0);
> > +  break;
> >  case 'l':
> >pc = new LocationPatternConverter(formattingInfo,
> >   FULL_LOCATION_CONVERTER);
> > @@ -391,6 +398,8 @@
> >   return event.getLevel().toString();
> >case NDC_CONVERTER:
> >   return event.getNDC();
> > +  case HOSTNAME_CONVERTER:
> > +return event.getHostname();
> >case MESSAGE_CONVERTER: {
> >   return event.getRenderedMessage();
> >}
> > diff -ru orig/src/java/org/apache/log4j/spi/LoggingEvent.java
> > src/java/org/apache/log4j/spi/LoggingEvent.java
> > --- orig/src/java/org/

RE: Hostname support in PatternLayout (patch included)

[Ceki Gülcü]

At 09:34 12.12.2002 -0800, you wrote:

Dan,

My only concern is the changing of LoggingEvent.  This object gets
serialized across sockets from one log4j process to another, so maintaining
some level of compatibility between different log4j versions is important.
Won't adding a new private member break serialization between versions?
Anyone?


No, adding fields does not break backward compatibility in the sense that 
clients version 'n' can send to server version 'n+1' where the difference 
between n and n+1 is the addition of an extra field. I don't remember what 
happens when n+1 sends to n.

That being said, I do agree that this functionality is useful.  We have
talked in the past about making changes in LoggingEvent that would make it
incompatible with earlier versions, but much faster serialized and maybe
more maintainable going forward.  Maybe v1.3 is the time to make the change.


Why stop at hostname? What about username? Session id? Cookies? Address of 
my dentist? You get the point. The JMS API solves this problem by having 
properties attached to each message. See 
http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/jms/Message.html


-Mark

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, December 12, 2002 8:34 AM
> To: [EMAIL PROTECTED]
> Subject: Hostname support in PatternLayout (patch included)
>
>
>
>
> Hi.
>
> I sent this patch in on Friday. It modifies PatternLayout so it can output
> the hostname via %h. It seems like it's simple enough for a developer to
> say good idea/bad idea, but it has slipped through the cracks.
> Therefore, I
> am submitting it again.
>
> Thanks
>
> Dan
>
>
> diff -ru
> orig/src/java/org/apache/log4j/helpers/PatternParser.java
> src/java/org/apache/log4j/helpers/PatternParser.java
> --- orig/src/java/org/apache/log4j/helpers/PatternParser.java
> 2002-10-09 18:50:03.0 -0400
> +++ src/java/org/apache/log4j/helpers/PatternParser.java
> 2002-12-05 12:19:13.0 -0500
> @@ -56,6 +56,7 @@
>static final int LEVEL_CONVERTER = 2002;
>static final int NDC_CONVERTER = 2003;
>static final int MESSAGE_CONVERTER = 2004;
> +  static final int HOSTNAME_CONVERTER = 2005;
>
>int state;
>protected StringBuffer currentLiteral = new StringBuffer(32);
> @@ -277,6 +278,12 @@
>//formattingInfo.dump();
>currentLiteral.setLength(0);
>break;
> +case 'h':
> +  pc = new BasicPatternConverter(formattingInfo, HOSTNAME_CONVERTER);
> +  //LogLog.debug("Hostname converter.");
> +  //formattingInfo.dump();
> +  currentLiteral.setLength(0);
> +  break;
>  case 'l':
>pc = new LocationPatternConverter(formattingInfo,
>   FULL_LOCATION_CONVERTER);
> @@ -391,6 +398,8 @@
>   return event.getLevel().toString();
>case NDC_CONVERTER:
>   return event.getNDC();
> +  case HOSTNAME_CONVERTER:
> +return event.getHostname();
>case MESSAGE_CONVERTER: {
>   return event.getRenderedMessage();
>}
> diff -ru orig/src/java/org/apache/log4j/spi/LoggingEvent.java
> src/java/org/apache/log4j/spi/LoggingEvent.java
> --- orig/src/java/org/apache/log4j/spi/LoggingEvent.java
> 2002-10-21 19:20:34.0 -0400
> +++ src/java/org/apache/log4j/spi/LoggingEvent.java   2002-12-06
> 11:03:44.0 -0500
> @@ -102,6 +102,9 @@
>/** The name of thread in which this logging event was generated. */
>private String threadName;
>
> +  /** The name of the host on which this logging event was generated. */
> +  private String hostName;
> +
>/** This
>variable contains information about this event's throwable
>*/
> @@ -142,6 +145,13 @@
>  this.categoryName = logger.getName();
>  this.level = priority;
>  this.message = message;
> +
> +try {
> +  this.hostName = java.net.InetAddress.getLocalHost().getHostName();
> +} catch (java.net.UnknownHostException uhe) {
> +  this.hostName = "*HOSTNAME UNKNOWN*";
> +}
> +
>  if (throwable != null) {
>this.throwableInfo = new ThrowableInformation(throwable);
>  }
> @@ -171,6 +181,13 @@
>  this.categoryName = logger.getName();
>  this.level = priority;
>  this.message = message;
> +
> +try {
> +  this.hostName = java.net.InetAddress.getLocalHost().getHostName();
> +} catch (java.net.UnknownHostException uhe) {
> +  this.hostName = "*HOSTNAME UNKNOWN*";
> +}
> +
>  if (throwable != null) {
>this.throwableInfo = new ThrowableInformation(th

RE: Hostname support in PatternLayout (patch included)

[mwomack]

Dan,

My only concern is the changing of LoggingEvent.  This object gets
serialized across sockets from one log4j process to another, so maintaining
some level of compatibility between different log4j versions is important.
Won't adding a new private member break serialization between versions?
Anyone?

That being said, I do agree that this functionality is useful.  We have
talked in the past about making changes in LoggingEvent that would make it
incompatible with earlier versions, but much faster serialized and maybe
more maintainable going forward.  Maybe v1.3 is the time to make the change.

-Mark

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, December 12, 2002 8:34 AM
> To: [EMAIL PROTECTED]
> Subject: Hostname support in PatternLayout (patch included)
>
>
>
>
> Hi.
>
> I sent this patch in on Friday. It modifies PatternLayout so it can output
> the hostname via %h. It seems like it's simple enough for a developer to
> say good idea/bad idea, but it has slipped through the cracks.
> Therefore, I
> am submitting it again.
>
> Thanks
>
> Dan
>
>
> diff -ru
> orig/src/java/org/apache/log4j/helpers/PatternParser.java
> src/java/org/apache/log4j/helpers/PatternParser.java
> --- orig/src/java/org/apache/log4j/helpers/PatternParser.java
> 2002-10-09 18:50:03.0 -0400
> +++ src/java/org/apache/log4j/helpers/PatternParser.java
> 2002-12-05 12:19:13.0 -0500
> @@ -56,6 +56,7 @@
>static final int LEVEL_CONVERTER = 2002;
>static final int NDC_CONVERTER = 2003;
>static final int MESSAGE_CONVERTER = 2004;
> +  static final int HOSTNAME_CONVERTER = 2005;
>
>int state;
>protected StringBuffer currentLiteral = new StringBuffer(32);
> @@ -277,6 +278,12 @@
>//formattingInfo.dump();
>currentLiteral.setLength(0);
>break;
> +case 'h':
> +  pc = new BasicPatternConverter(formattingInfo, HOSTNAME_CONVERTER);
> +  //LogLog.debug("Hostname converter.");
> +  //formattingInfo.dump();
> +  currentLiteral.setLength(0);
> +  break;
>  case 'l':
>pc = new LocationPatternConverter(formattingInfo,
>   FULL_LOCATION_CONVERTER);
> @@ -391,6 +398,8 @@
>   return event.getLevel().toString();
>case NDC_CONVERTER:
>   return event.getNDC();
> +  case HOSTNAME_CONVERTER:
> +return event.getHostname();
>case MESSAGE_CONVERTER: {
>   return event.getRenderedMessage();
>}
> diff -ru orig/src/java/org/apache/log4j/spi/LoggingEvent.java
> src/java/org/apache/log4j/spi/LoggingEvent.java
> --- orig/src/java/org/apache/log4j/spi/LoggingEvent.java
> 2002-10-21 19:20:34.0 -0400
> +++ src/java/org/apache/log4j/spi/LoggingEvent.java   2002-12-06
> 11:03:44.0 -0500
> @@ -102,6 +102,9 @@
>/** The name of thread in which this logging event was generated. */
>private String threadName;
>
> +  /** The name of the host on which this logging event was generated. */
> +  private String hostName;
> +
>/** This
>variable contains information about this event's throwable
>*/
> @@ -142,6 +145,13 @@
>  this.categoryName = logger.getName();
>  this.level = priority;
>  this.message = message;
> +
> +try {
> +  this.hostName = java.net.InetAddress.getLocalHost().getHostName();
> +} catch (java.net.UnknownHostException uhe) {
> +  this.hostName = "*HOSTNAME UNKNOWN*";
> +}
> +
>  if (throwable != null) {
>this.throwableInfo = new ThrowableInformation(throwable);
>  }
> @@ -171,6 +181,13 @@
>  this.categoryName = logger.getName();
>  this.level = priority;
>  this.message = message;
> +
> +try {
> +  this.hostName = java.net.InetAddress.getLocalHost().getHostName();
> +} catch (java.net.UnknownHostException uhe) {
> +  this.hostName = "*HOSTNAME UNKNOWN*";
> +}
> +
>  if (throwable != null) {
>this.throwableInfo = new ThrowableInformation(throwable);
>  }
> @@ -190,6 +207,13 @@
>}
>
>/**
> +   * Return the hostname of this event. Use this form instead of directly
> +   * accessing the hostName field. */
> +  public String getHostname() {
> +return hostName;
> +  }
> +
> +  /**
> * Return the level of this event. Use this form instead of directly
> * accessing the level field.  */
>public Level getLevel() {
>
>
>
> --
> -
> This message and any included attachments are from Siemens
>

Hostname support in PatternLayout (patch included)

[Daniel . Hannum]

Hi.

I sent this patch in on Friday. It modifies PatternLayout so it can output
the hostname via %h. It seems like it's simple enough for a developer to
say good idea/bad idea, but it has slipped through the cracks. Therefore, I
am submitting it again.

Thanks

Dan


diff -ru orig/src/java/org/apache/log4j/helpers/PatternParser.java 
src/java/org/apache/log4j/helpers/PatternParser.java
--- orig/src/java/org/apache/log4j/helpers/PatternParser.java 2002-10-09 
18:50:03.0 -0400
+++ src/java/org/apache/log4j/helpers/PatternParser.java2002-12-05 
+12:19:13.0 -0500
@@ -56,6 +56,7 @@
   static final int LEVEL_CONVERTER = 2002;
   static final int NDC_CONVERTER = 2003;
   static final int MESSAGE_CONVERTER = 2004;
+  static final int HOSTNAME_CONVERTER = 2005;

   int state;
   protected StringBuffer currentLiteral = new StringBuffer(32);
@@ -277,6 +278,12 @@
   //formattingInfo.dump();
   currentLiteral.setLength(0);
   break;
+case 'h':
+  pc = new BasicPatternConverter(formattingInfo, HOSTNAME_CONVERTER);
+  //LogLog.debug("Hostname converter.");
+  //formattingInfo.dump();
+  currentLiteral.setLength(0);
+  break;
 case 'l':
   pc = new LocationPatternConverter(formattingInfo,
  FULL_LOCATION_CONVERTER);
@@ -391,6 +398,8 @@
  return event.getLevel().toString();
   case NDC_CONVERTER:
  return event.getNDC();
+  case HOSTNAME_CONVERTER:
+return event.getHostname();
   case MESSAGE_CONVERTER: {
  return event.getRenderedMessage();
   }
diff -ru orig/src/java/org/apache/log4j/spi/LoggingEvent.java 
src/java/org/apache/log4j/spi/LoggingEvent.java
--- orig/src/java/org/apache/log4j/spi/LoggingEvent.java2002-10-21 
19:20:34.0 -0400
+++ src/java/org/apache/log4j/spi/LoggingEvent.java   2002-12-06 11:03:44.0 
+-0500
@@ -102,6 +102,9 @@
   /** The name of thread in which this logging event was generated. */
   private String threadName;

+  /** The name of the host on which this logging event was generated. */
+  private String hostName;
+
   /** This
   variable contains information about this event's throwable
   */
@@ -142,6 +145,13 @@
 this.categoryName = logger.getName();
 this.level = priority;
 this.message = message;
+
+try {
+  this.hostName = java.net.InetAddress.getLocalHost().getHostName();
+} catch (java.net.UnknownHostException uhe) {
+  this.hostName = "*HOSTNAME UNKNOWN*";
+}
+
 if (throwable != null) {
   this.throwableInfo = new ThrowableInformation(throwable);
 }
@@ -171,6 +181,13 @@
 this.categoryName = logger.getName();
 this.level = priority;
 this.message = message;
+
+try {
+  this.hostName = java.net.InetAddress.getLocalHost().getHostName();
+} catch (java.net.UnknownHostException uhe) {
+  this.hostName = "*HOSTNAME UNKNOWN*";
+}
+
 if (throwable != null) {
   this.throwableInfo = new ThrowableInformation(throwable);
 }
@@ -190,6 +207,13 @@
   }

   /**
+   * Return the hostname of this event. Use this form instead of directly
+   * accessing the hostName field. */
+  public String getHostname() {
+return hostName;
+  }
+
+  /**
* Return the level of this event. Use this form instead of directly
* accessing the level field.  */
   public Level getLevel() {



---
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:   
For additional commands, e-mail: 

Hostname support in PatternLayout (patch included)

[Daniel . Hannum]

Hi.

I'm using Log4j in an enterprise logging solution and interestingly, the
_only_ extension that we need to make is to allow applications to log their
hostname, preferably in PatternLayout. While I could extend PatternParser
to do it, I would then have to extend PatternLayout so it would use the new
PatternParser. And then I'd have to extend JDBCAppender so it would use the
new PatternLayout. And I find that extra maintenance to be stupid when all
I want is a specifier for the hostname, which I think should have been
there in the first place.

Thus, I patched the latest CVS tree to do exactly that. Now, %h in
PatternLayout will print the hostname. Hopefully, it'll make its way into
the next point release and then I can just use stock Log4j without needing
to extend things.

Thanks

Dan


diff -ru orig/src/java/org/apache/log4j/helpers/PatternParser.java 
src/java/org/apache/log4j/helpers/PatternParser.java
--- orig/src/java/org/apache/log4j/helpers/PatternParser.java 2002-10-09 
18:50:03.0 -0400
+++ src/java/org/apache/log4j/helpers/PatternParser.java2002-12-05 
+12:19:13.0 -0500
@@ -56,6 +56,7 @@
   static final int LEVEL_CONVERTER = 2002;
   static final int NDC_CONVERTER = 2003;
   static final int MESSAGE_CONVERTER = 2004;
+  static final int HOSTNAME_CONVERTER = 2005;

   int state;
   protected StringBuffer currentLiteral = new StringBuffer(32);
@@ -277,6 +278,12 @@
   //formattingInfo.dump();
   currentLiteral.setLength(0);
   break;
+case 'h':
+  pc = new BasicPatternConverter(formattingInfo, HOSTNAME_CONVERTER);
+  //LogLog.debug("Hostname converter.");
+  //formattingInfo.dump();
+  currentLiteral.setLength(0);
+  break;
 case 'l':
   pc = new LocationPatternConverter(formattingInfo,
  FULL_LOCATION_CONVERTER);
@@ -391,6 +398,8 @@
  return event.getLevel().toString();
   case NDC_CONVERTER:
  return event.getNDC();
+  case HOSTNAME_CONVERTER:
+return event.getHostname();
   case MESSAGE_CONVERTER: {
  return event.getRenderedMessage();
   }
diff -ru orig/src/java/org/apache/log4j/spi/LoggingEvent.java 
src/java/org/apache/log4j/spi/LoggingEvent.java
--- orig/src/java/org/apache/log4j/spi/LoggingEvent.java2002-10-21 
19:20:34.0 -0400
+++ src/java/org/apache/log4j/spi/LoggingEvent.java   2002-12-06 11:03:44.0 
+-0500
@@ -102,6 +102,9 @@
   /** The name of thread in which this logging event was generated. */
   private String threadName;

+  /** The name of the host on which this logging event was generated. */
+  private String hostName;
+
   /** This
   variable contains information about this event's throwable
   */
@@ -142,6 +145,13 @@
 this.categoryName = logger.getName();
 this.level = priority;
 this.message = message;
+
+try {
+  this.hostName = java.net.InetAddress.getLocalHost().getHostName();
+} catch (java.net.UnknownHostException uhe) {
+  this.hostName = "*HOSTNAME UNKNOWN*";
+}
+
 if (throwable != null) {
   this.throwableInfo = new ThrowableInformation(throwable);
 }
@@ -171,6 +181,13 @@
 this.categoryName = logger.getName();
 this.level = priority;
 this.message = message;
+
+try {
+  this.hostName = java.net.InetAddress.getLocalHost().getHostName();
+} catch (java.net.UnknownHostException uhe) {
+  this.hostName = "*HOSTNAME UNKNOWN*";
+}
+
 if (throwable != null) {
   this.throwableInfo = new ThrowableInformation(throwable);
 }
@@ -190,6 +207,13 @@
   }

   /**
+   * Return the hostname of this event. Use this form instead of directly
+   * accessing the hostName field. */
+  public String getHostname() {
+return hostName;
+  }
+
+  /**
* Return the level of this event. Use this form instead of directly
* accessing the level field.  */
   public Level getLevel() {





---
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:   
For additional commands, e-mail: