interfaces for Message classes

[John Vasileff <jo...@gmail.com>]

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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org