logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joern Huxhorn <jhuxh...@googlemail.com>
Subject Re: log4j2 parameterized msg with throwable
Date Fri, 16 Sep 2011 23:41:36 GMT

On 16.09.2011, at 19:09, John Vasileff wrote:

> On Sep 15, 2011, at 7:46 PM, Ralph Goers wrote:
>> My gut reaction is that I agree with you. I ran across this behavior a while ago
and Joern mentioned that ParameterizedMessage was working the way it is supposed to, which
given the behavior you are noting just doesn't seem correct.
>> On the other hand, currently not every Message implementation cares about Throwables.
 I'm not sure what StructuredDataMessage should do with one, for example.  What do you think
should be done to handle that?
> I think it is analogous to getParameters().  It is a common feature, but not one that
all Message types need.  So I think the question is how granular the interfaces should be.
 Message could have _only_ getFormattedMessage(), and everything else added by sub interfaces.
 But for very common things like Throwables or Parameters, I tend to think it is easier to
have them in the main Message interface and avoid instanceof clutter in the rest of the code.

I wonder why you are so keen to extend the basic Message interface with arbitrary methods
that are only relevant for certain Message implementations?

The Runnable interface does also only have a run() method and not some obscure Object[] getArguments()
/ void setArguments(Object[]) methods.

> SimpleMessage has:
>    /**
>     * Returns null since there are no parameters.
>     * @return null.
>     */
>    public Object[] getParameters() {
>        return null;
>    }
> So StructuredDataMessage can have:
>    /**
>     * @return null; StrucutredDataMessages never have Throwables.
>     */
>    public Throwable getThrowable() {
>        return null;
>    }

But what about tracing messages? Those could have a TraceMessageType (ENTERING, EXITING, THROWING).
Shouldn't we add that to the Message interface, too, and just return null in case of every
other Message implementation?

Sorry about my sarcasm (and yes, that's only sarcasm. I'm not suggesting to add this to the
Message interface ;)) but I just don't see the reason and rationale for those methods.

To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message