By accepting argument of type String[] in its constructor [1],
ParameterizedMessage trades immutability for typing information.
However, the typing information is required for filtering. So losing
typing information is a relatively important loss. Is
ParameterizedMessage typical or an unfortunate counter example?
As for immutability, a careless/malicious developer can still modify the
contents of the String[] array. Thus, there is a limit to the level of
protection gained from converting Object[] to String[].
Let's work on a concrete example. Let's say we are working on airspace
control system which needs to log flight records.
Here is a very minimal impl:
FlightRecord {
public String flightCode; // SA 457
public long[] currentGPSCoordinates; // the GPS coordinate
FlightRecord(String flightCode, long[] currentGPSCoordinates) { ... }
}
So given a FlightRecord:
FlightRecord fr = new FlightRecord("SA 456", new long[] {1, 1, 1}}
using log4j we would write
logger.info(fr);
and using SLF4J we would write
logger.info("{}", fr);
In both approaches the FlightRecord instance is mutable.
We could write a wrapper, say FlightRecordWrapper, to render
FlightRecord immutable:
FlightRecordWrapper implements Message {
final String flightCode;
final long[] currentGPSCoordinates;
FlightRecordWrapper(FlightRecord fr) {
flightCode = fr.flightCode;
currentGPSCoordinates = fr.currentGPSCoordinates.clone();
}
}
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.
--
Ceki
[1]
https://github.com/huxi/slf4j/blob/slf4j-redesign/slf4j-n-api/src/main/java/org/slf4j/n/messages/ParameterizedMessage.java
On 10.09.2011 14:02, Joern Huxhorn wrote:
Hi Ceki,
You are right, the perceived behavior is the same in case of, say, a console
appender.
But the lazy evaluation is actually one of the issues that I'm trying to
resolve.
I'd like to prevent an issue like this at all costs:
http://techblog.appnexus.com/2011/webkit-chrome-safari-console-log-bug/
If the arguments are kept as Object[] instead of converting them to Strings in
the same Thread and at the time of the logger call then stuff like this can
happen in case of asynchronous appenders. Hibernate can also throw
LazyInitializationException if lazy members are accessed outside of the
surrounding transaction. My example of an appender that serves events to the
view of a webapp in my previous mail would be one example of that. If a member
of one of it's arguments is changed before the message is created then it would
behave like the webkit bug above.
Because of this, I convert all arguments to their String representation while
creating the ParameterizedMessage (only after the checks have determined that
the call should actually emit an event, obviously). This, in turn, means that
the types/original objects are lost in the process, making it impossible to
filter on them.
Something similar must be done regardless of the existance of a Message
interface/implementation. (I remember that we discussed this in the past but I
don't know if I was able to convince you about how crucial I consider this -
nothing is worse than a lying logging framework. Other than a logging framework
crashing the application, of course, but I think we nailed that already in the
MessageFormatter.)
Since the creation of a Message instance is rather expensive I assume that a
performance-conscious person will surround it with a isXxxEnabled() guard. I
further assume that Message implementations take care of transforming
critical/mutable Objects into String or some other thread-safe/immutable type
during creation. Otherwise I'd consider that a bug in the Message
implementation. I thought about adding a prepareForDeferredProcessing() method
to the Message interface but decided against it. I'd instead document this
necessity in the Message interface.
In #148 Ralph requested the ability to log StructuredData without having to parse the
String representation. This could be done using a StructuredDataMessage that contains
the key/value pairs in a Map<String, String>, meaning it would still contain
the Map but wouldn't contain any mutable instances anymore, making it thread-safe.
Beside all this I really do like the expressiveness gained compared to the "workaround"
of info("{}", sd).
info(Message) is like an info(Object) method, but with a "type-safe
documentation" attached by means of the Message interface.
I'd, personally, consider it bad style to just dump any object in a log
message. So I wouldn't allow or encourage this and therefore wouldn't want to
add an info(Object) signature to the logger.
Hope this explains the difference sufficiently,
Joern.
On 09.09.2011, at 23:54, Ceki Gülcü wrote:
Hi everyone,
After reading this thread, I am still trying to establish whether the
Message interface is needed especially compared to the following
approach:
StructuredData sd = new StructuredData(..., aMap, ...);
logger.info("{}", sd);
Granted, the above is not intuitive but other than that:
1) it allows filtering on parameter type
2) formatting of StructuredData is done lazily using the toString
method of StructuredData
3) it requires no changes to SLF4J
I do not wish to be obtuse and I apologize if this question was asked
previously. Unfortunately, I don't recall the answer. Seriously, what
is wrong with logger.info("{}", sd) ?
Cheers,
--
Ceki
_______________________________________________
slf4j-dev mailing list
[email protected]
http://qos.ch/mailman/listinfo/slf4j-dev
_______________________________________________
slf4j-dev mailing list
[email protected]
http://qos.ch/mailman/listinfo/slf4j-dev
--
QOS.ch, main sponsor of cal10n, logback and slf4j open source projects,
is looking to hire talented software engineers. For further details, see
http://logback.qos.ch/job.html
_______________________________________________
slf4j-dev mailing list
[email protected]
http://qos.ch/mailman/listinfo/slf4j-dev
