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.
Joern
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
