Hi Tim,
The change seems innocuous enough. It increases flexibility without
impacting efficiency as far as I can tell. One might even consider adding
a "setter" for the timestamp to allow modification even after the creation
of the event object.
In addition to the flexibility needed for your needs, this would allow
implementations of socket server to be configured as to whether to log the
time the event was created vs the time it arrived at the logging server.
When the timestamp is set to event creation time, it is easy to reconcile
remotely logged events to other events that occurred on the machine of
origin. It is more difficult to reconcile this events with those that
occur on other machines since on most systems, the clocks are not perfectly
synchronized. By setting the time stamp to arrival time, all the remote
events are timestamped by the same clock; albeit one that had to wait a few
milliseconds for the event to arrive. So relative timings between events
on different machines are more relevant. But reconciling these timing with
non-log4j events (such as those recorded by a remote operating system or
application server log) becomes more difficult due to the different clocks
in use.
I would give a +1 for this change (to the LoggingEvent class).
When Ceki referred to my "opinions" on this, I'm not sure if he was
referring to my above rant or to the bit about changing LoggingEvent can
cause serialization mismatch failures between remote loggers unless both
sides are upgraded at the same time. This can become trouble as the
logging network becomes more elaborate.
Making the serialization less susceptible to changes is one of the items on
my log4j to-do list (which will require yet another change incompatible
with previous versions of LoggingEvent :) ).
- Paul
Paul Glezen
IT Specialist
Software Services
818 539 3321
Ceki Gulcu <[EMAIL PROTECTED]> on 05/04/2001 12:55:14 AM
Please respond to "LOG4J Developers Mailing List"
<[EMAIL PROTECTED]>
To: LOG4J Developers Mailing List <[EMAIL PROTECTED]>
cc:
Subject: Re: [PATCH] Logging Event
Hi Tim,
Thanks for the new LoggingEvent.java file. As a side
note, please keep in mind that unified diffs (diff -u)
is the preferred way for suppying patches. This is
clearly not a big deal.
Coming back to the question of the timestamp, let me
say that the LoggingEvent class is designed with
safety and speed in mind, not flexiblity. This can be
considered as a design trade off (flaw?). It seems to
me that the fact that you could retrofit your
requirement to the existing design (with very little
modification) is due to your creativity and a pinch of
luck.
I am not sure other requirements could be added with
such ease. We should perhaps take the time to review
the design of the LoggingEvent class with more
flexibility in mind.
Paul Glezen is known to have opinions on the
subject.... Cheers, Ceki
--- Tim Dwelle <[EMAIL PROTECTED]> wrote:
> I have been using Log4J 1.1b6 to log messages that I
> pull
> off a JMS publish-subscribe topic. I'd like the
> timeStamp
> of the logging event to reflect the time the message
> was
> sent via JMS, rather than the time our subscriber
> gets
> around to logging the message.
>
> The current LoggingEvent derives the timeStamp when
> it is
> constructed, and that value cannot be changed (since
> the
> attribute is final). Attached is a modified version
> of
> LoggingEvent, with an alternate constructor allowing
> you
> to specify the timeStamp of the event.
>
> While I realize most people shouldn't need this...
> the
> change is extremely trivial and does make the system
> more
> flexible. And it would help me out a bunch!
>
> Thanks.
>
> - Tim Dwelle
> [EMAIL PROTECTED]
>
>
>
> ATTACHMENT part 2 application/octet-stream
name=LoggingEvent.java
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
[EMAIL PROTECTED]
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/
---------------------------------------------------------------------
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]
