RFC5424Layout and others use "msg instanceof StructuredDataMessage".
StructuredData is a class, but if it were an interface, alternate
implementations of StructuredData could be supported.
One case for this would be if (hypothetically) SLF4J had it's own
SLF4JStructuredDataMessage, and passed objects of that type to log4j. Using
interfaces would allow the SLF4JStructuredDataMessage to be wrapped by an
adapter to create a Log4jStructuredDataMessage rather than creating a new
"heavy" object and copying values.
ParameterizedMessage is another case. But, the api for ParameterizedMessage
may be very similar to JavaUtilFormatterMessage proposed in SLF4J by Joern.
Wrapping performed by Log4j's SLF4JLogger should be agnostic to minor
differences in a particular message's implementation.
So, both SLF4J and Log4j could have interfaces that described
ParameterizedMessage (and others). Interfaces would include methods such as
getParameters(), getMessagePattern(), etc.
SLF4JLogger code would look like:
// handle trace(msg) specified by a hypothetical SLF4J 2.0.
public void trace(SLF4JMessage msg) {
if(logger.isTraceEnabled() {
logger.trace(slf4jToLog4j(msg));
}
}
static Log4jMessage slf4jToLog4j(SLF4JMessage msg) {
if (msg instanceof SLF4JStructuredData) {
return new SDWrapper((SLF4JStructuredDataMessage) msg);
} // else handle other complex types
// fallback with support for shared generic features
return new SLF4JMessageWrapper(msg);
}
SLF4JMessageWrapper would implement most of the fine grained Message interfaces
such as Message, LoggerNameAwareMessage, ParamMessage, FormattedMessage, etc.
Features common to both slf4j & log4j messages would be supported.
John
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
