[slf4j-dev] Benefits of Message objects?

[Ralph Goers]

One other thing I should point out.  The argument regarding

logger.error(message)

vs

logger.error("{}", message object)

is in large degree about type safety. Java is strongly typed for a reason. Object has very few defined behaviors. A Message interface allows more well defined operations to be added. Furthermore, it allows other "decorator" interfaces to be made available. For example, I found the need to add a LoggerNameAwareMessage interface so that the Message could have knowledge of the name of the logger that was using it.  

The problem with the point of view that says the above two snippets are identical is that it assumes that the message will only be treated as an Object converted to a String. To assume more than that should require using an appropriate data type.  This is exposed in your FlightRecord example as you assume that the FlightRecordMessage has no other behaviors where it might interact with the logging system.  What if I want to provide a way to have a Layout or Encoder pass configuration information to the Message in a standard way? I can do that through the Message interface but not through some arbitrary object.

Ralph


On Sep 10, 2011, at 12:50 PM, Ceki Gülcü wrote:

> On 10/09/2011 5:19 PM, Ralph Goers wrote:
>> 
>> On Sep 10, 2011, at 6:50 AM, Ceki Gulcu wrote:
>> 
>>> If the Message interface were supported in SLF4J, we would write:
>>> 
>>>  logger.info(new FlightRecordWrapper(fr));
>>> 
>>> This is cleaner than
>>> 
>>>  logger.info("{}", new FlightRecordWrapper(fr));
>>> 
>>> I am still left with the feeling that the main inconvenience of the "{}" form is its ugliness.
>>> 
> > Not just its ugliness. Logback always formats the message when
> > creating the event which will convert FlightRecordWrapper.  I can
> > imagine a use case where I filter FlightRecordMessages to a particular
> > Appender and then serialize them using Avro, Hession or something
> > similar so generating the formatted message is unnecessary.
> 
> Invocation of FormattingTuple.format in LoggingEvent is there to keep the code simple. Eager formatting could be done lazily as long as the data remains unchanged and/or is non-mutable.
> 
> > It is also much easier to write Appenders or Layouts that simply do
> 
>> if (message instanceOf MyMessage) {
>>   MyMessage myMsg = (MyMessage) message;
>>   //  do stuff to my message
>> } else {
>>   // do something else
>> }
>> 
>> rather than
>> 
>> MyMessage myMsg = null;
>> for (Object obj : event.getArgumentArray()) {
>>   If (obj instanceOf MyMessage) {
>>     myMsg = (MyMessage) obj;
>>     break;
>>   }
>> }
>> 
>> if (myMsg != null) {
>>   // Do stuff to my message
>> } else {
>>   // do something else.
>> }
> 
> Yes, indeed. Good point.
> 
> > I should also note that at some point LocationAwareLogger wasn't
> > even passing the argument array so EventLogger had to convert the
> > EventData to an XML String. When you added the argument array to
> > LocationAwareLogger you modified EventLogger to pass a null, not the
> > EventData object. So using EventLogger is very expensive.
> 
> It would be trivial to correct EventLogger wouldn't it?
> 
> -- 
> QOS.ch, main sponsor of cal10n, logback and slf4j open source projects, is looking to hire talented software developers. For further details, see http://logback.qos.ch/job.html
> _______________________________________________
> slf4j-dev mailing list
> slf4j-dev at qos.ch
> http://qos.ch/mailman/listinfo/slf4j-dev