You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by Hein Meling <me...@acm.org> on 2004/12/17 13:01:44 UTC
MDC signature change in log4j v1.3
Ciao,
I've noticed that MDC.put(String, Object) has been deprecated and is
being replaced by MDC.put(String, String) instead. At first, I didn't
think of this as a problem other than calling the Object.toString()
method instead.
But, later I discovered that this is flawed, because the Object might
change its state (and hence toString() output might be different)
between debug calls. Consider my example:
Group g = new Group(1);
g.setState(IDLE);
MDC.put("group", g.toString());
log.debug("Hi");
g.setState(SYNC);
log.debug("Ciao");
This sequence, will result in both debug statements printing the same
state (IDLE) even if in SYNC state, as opposed to using the now
deprecated method (actually the 1.3 version does not work; it does work
in 1.2.8 though):
MDC.put("group", g);
which would print the correct state.
To overcome this problem, I would have to identify every location that
modify the state of the Group object, and update the MDC entry, causing
a lot of clutter.
So to my question: is this signature change in 1.3alpha3 really
warranted?? Is there a good reason for it?
Thanks,
Hein
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: MDC signature change in log4j v1.3
Posted by Hein Meling <me...@acm.org>.
Hello Ceki,
Thanks for being so forthcoming about this. I realize that there may be
a certain overhead with this, but hopefully the benefits of this later
rendering will outweigh its overhead penelty. If the overhead is
significant, you may consider if you wish to support both the dynamic
and static modes. But then again, I don't fully understand the internal
implications that this might have.
Thanks again,
Hein
fre, 17,.12.2004 kl. 15.44 +0100, skrev Ceki Gülcü:
> Hello Hein,
>
> Thank you for your informative and precise message. The signature
> change in of the MDC.put and MDC.get messages in 1.3 has two, albeit
> partial, justifications.
>
> First, in log4j 1.3 you can attach properties to a logger repository
> so that all components attached to that repository, such as loggers,
> appenders, layouts, inherit those properties. However, the values of
> these properties are of type String. When log4j 1.3 internally
> processes logging events, the MDC properties and loggerRepository
> properties are viewed as properties of the logging event being
> processed. There is no distinction between properties originating in
> the MDC and those properties originating in the containing
> LoggerRepository. In short, the MDC properties and LoggerRepository
> properties are merged inside the logging event. This merging
> operation is easier to do if the values are all of the same type,
> namely String.
>
> The second reason has to do with the way LoggingEvents are
> serialized. Data supplied by the user such as MDC properties or the
> event's message are transformed into type String before transmission
> over the wire.
>
> So it seemed reasonable to impose that the MDC data be of type String
> right from the start. However, your remarks show that this premise has
> important drawbacks from the user's perspective, which I have to
> admit, I was not aware of.
>
> If the overhead incurred while merging the MDC properties and
> LoggerRepository properties increases significantly when the type of
> MDC properties is Object instead of String, then the current
> signatures are preferable. However, if the additional overhead is
> small, then obviously we will revert to the old signature.
>
> I am opening a bug report relative this issue.
>
> Thanks again for your enlightening remarks,
>
> At 01:01 PM 12/17/2004, Hein Meling wrote:
> >Ciao,
> >
> >I've noticed that MDC.put(String, Object) has been deprecated and is
> >being replaced by MDC.put(String, String) instead. At first, I didn't
> >think of this as a problem other than calling the Object.toString()
> >method instead.
> >
> >But, later I discovered that this is flawed, because the Object might
> >change its state (and hence toString() output might be different)
> >between debug calls. Consider my example:
> >
> > Group g = new Group(1);
> > g.setState(IDLE);
> > MDC.put("group", g.toString());
> > log.debug("Hi");
> > g.setState(SYNC);
> > log.debug("Ciao");
> >
> >This sequence, will result in both debug statements printing the same
> >state (IDLE) even if in SYNC state, as opposed to using the now
> >deprecated method (actually the 1.3 version does not work; it does work
> >in 1.2.8 though):
> >
> > MDC.put("group", g);
> >
> >which would print the correct state.
> >
> >To overcome this problem, I would have to identify every location that
> >modify the state of the Group object, and update the MDC entry, causing
> >a lot of clutter.
> >
> >So to my question: is this signature change in 1.3alpha3 really
> >warranted?? Is there a good reason for it?
> >
> >Thanks,
> >
> >Hein
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: MDC signature change in log4j v1.3
Posted by Curt Arnold <ca...@houston.rr.com>.
On Mar 1, 2005, at 7:14 AM, Hein Meling wrote:
> Hello Ceki,
>
> What is the status of the bug (32752) related to this (I see no
> additional comment or change to the bug report)?
>
> I hope that the signature will be reverted to that of log4j 1.2, so
> that
> usability can be preserved.
>
> Hein
>
I have a pending task to review and streamline LoggingEvent and was
expect to do this work in conjuction with that effort.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: MDC signature change in log4j v1.3
Posted by Hein Meling <me...@acm.org>.
Hello Ceki,
What is the status of the bug (32752) related to this (I see no
additional comment or change to the bug report)?
I hope that the signature will be reverted to that of log4j 1.2, so that
usability can be preserved.
Hein
fre, 25,.02.2005 kl. 10.23 +0000, skrev Vinay Sajip:
> Hello Ceki,
>
> > First, in log4j 1.3 you can attach properties to a logger repository
> > so that all components attached to that repository, such as loggers,
> > appenders, layouts, inherit those properties. However, the values of
> > these properties are of type String. When log4j 1.3 internally
> > processes logging events, the MDC properties and loggerRepository
> > properties are viewed as properties of the logging event being
> > processed. There is no distinction between properties originating in
> > the MDC and those properties originating in the containing
> > LoggerRepository. In short, the MDC properties and LoggerRepository
> > properties are merged inside the logging event. This merging
> > operation is easier to do if the values are all of the same type,
> > namely String.
>
> OK, but you can document that all objects in the MDC will have toString() called
> at the appropriate point. Then the developer can provide a suitable toString()
> for their needs.
>
> > The second reason has to do with the way LoggingEvents are
> > serialized. Data supplied by the user such as MDC properties or the
> > event's message are transformed into type String before transmission
> > over the wire.
>
> This could be done via toString(), as above.
>
> > So it seemed reasonable to impose that the MDC data be of type String
> > right from the start. However, your remarks show that this premise has
> > important drawbacks from the user's perspective, which I have to
> > admit, I was not aware of.
> >
> > If the overhead incurred while merging the MDC properties and
> > LoggerRepository properties increases significantly when the type of
> > MDC properties is Object instead of String, then the current
> > signatures are preferable. However, if the additional overhead is
> > small, then obviously we will revert to the old signature.
>
> The additional overhead involved is effectively calling toString() on all
> entries in the MDC, which is minimal if users add Strings to the MDC; in the
> case of other objects, the price they pay is that of their toString()
> implementation.
>
> Best regards,
>
>
> Vinay Sajip
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
Re: MDC signature change in log4j v1.3
Posted by Vinay Sajip <vi...@yahoo.co.uk>.
Hello Ceki,
> First, in log4j 1.3 you can attach properties to a logger repository
> so that all components attached to that repository, such as loggers,
> appenders, layouts, inherit those properties. However, the values of
> these properties are of type String. When log4j 1.3 internally
> processes logging events, the MDC properties and loggerRepository
> properties are viewed as properties of the logging event being
> processed. There is no distinction between properties originating in
> the MDC and those properties originating in the containing
> LoggerRepository. In short, the MDC properties and LoggerRepository
> properties are merged inside the logging event. This merging
> operation is easier to do if the values are all of the same type,
> namely String.
OK, but you can document that all objects in the MDC will have toString() called
at the appropriate point. Then the developer can provide a suitable toString()
for their needs.
> The second reason has to do with the way LoggingEvents are
> serialized. Data supplied by the user such as MDC properties or the
> event's message are transformed into type String before transmission
> over the wire.
This could be done via toString(), as above.
> So it seemed reasonable to impose that the MDC data be of type String
> right from the start. However, your remarks show that this premise has
> important drawbacks from the user's perspective, which I have to
> admit, I was not aware of.
>
> If the overhead incurred while merging the MDC properties and
> LoggerRepository properties increases significantly when the type of
> MDC properties is Object instead of String, then the current
> signatures are preferable. However, if the additional overhead is
> small, then obviously we will revert to the old signature.
The additional overhead involved is effectively calling toString() on all
entries in the MDC, which is minimal if users add Strings to the MDC; in the
case of other objects, the price they pay is that of their toString()
implementation.
Best regards,
Vinay Sajip
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: MDC signature change in log4j v1.3
Posted by Ceki Gülcü <ce...@qos.ch>.
Hello Hein,
Thank you for your informative and precise message. The signature
change in of the MDC.put and MDC.get messages in 1.3 has two, albeit
partial, justifications.
First, in log4j 1.3 you can attach properties to a logger repository
so that all components attached to that repository, such as loggers,
appenders, layouts, inherit those properties. However, the values of
these properties are of type String. When log4j 1.3 internally
processes logging events, the MDC properties and loggerRepository
properties are viewed as properties of the logging event being
processed. There is no distinction between properties originating in
the MDC and those properties originating in the containing
LoggerRepository. In short, the MDC properties and LoggerRepository
properties are merged inside the logging event. This merging
operation is easier to do if the values are all of the same type,
namely String.
The second reason has to do with the way LoggingEvents are
serialized. Data supplied by the user such as MDC properties or the
event's message are transformed into type String before transmission
over the wire.
So it seemed reasonable to impose that the MDC data be of type String
right from the start. However, your remarks show that this premise has
important drawbacks from the user's perspective, which I have to
admit, I was not aware of.
If the overhead incurred while merging the MDC properties and
LoggerRepository properties increases significantly when the type of
MDC properties is Object instead of String, then the current
signatures are preferable. However, if the additional overhead is
small, then obviously we will revert to the old signature.
I am opening a bug report relative this issue.
Thanks again for your enlightening remarks,
At 01:01 PM 12/17/2004, Hein Meling wrote:
>Ciao,
>
>I've noticed that MDC.put(String, Object) has been deprecated and is
>being replaced by MDC.put(String, String) instead. At first, I didn't
>think of this as a problem other than calling the Object.toString()
>method instead.
>
>But, later I discovered that this is flawed, because the Object might
>change its state (and hence toString() output might be different)
>between debug calls. Consider my example:
>
> Group g = new Group(1);
> g.setState(IDLE);
> MDC.put("group", g.toString());
> log.debug("Hi");
> g.setState(SYNC);
> log.debug("Ciao");
>
>This sequence, will result in both debug statements printing the same
>state (IDLE) even if in SYNC state, as opposed to using the now
>deprecated method (actually the 1.3 version does not work; it does work
>in 1.2.8 though):
>
> MDC.put("group", g);
>
>which would print the correct state.
>
>To overcome this problem, I would have to identify every location that
>modify the state of the Group object, and update the MDC entry, causing
>a lot of clutter.
>
>So to my question: is this signature change in 1.3alpha3 really
>warranted?? Is there a good reason for it?
>
>Thanks,
>
>Hein
--
Ceki Gülcü
The complete log4j manual: http://qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org