I'd suspect in those cases where you were trying to get a log viewer to process the events, you wouldn't bother passing custom objects via TCP unless you wanted to develop a custom receiver to parse it...In Chainsaw's case, I'd suggest using (VFS)LogFilePatternReceiver to process the events (just include an additional appender).
Scott On Mon, Feb 22, 2010 at 12:22 AM, Ralph Goers <[email protected]>wrote: > > On Feb 21, 2010, at 8:22 PM, Curt Arnold wrote: > > > > > On Feb 20, 2010, at 11:16 AM, Ralph Goers wrote: > >> > >> I'd prefer a Message instead of an Object. The primary difference is > that the Message is an interface that looks like: > >> > >> /** > >> * An interface for various Message implementations that can be logged. > >> */ > >> public interface Message extends Serializable { > >> /** > >> * Returns the Message formatted as a String. > >> * @return The message String. > >> */ > >> String getFormattedMessage(); > >> > >> /** > >> * Returns the format portion of the Message > >> * @return > >> */ > >> String getMessageFormat(); > >> > >> /** > >> * Returns parameter values, if any. > >> * @return An array of parameter values or null. > >> */ > >> Object[] getParameters(); > >> } > >> > >> For SLF4J I implemented a ParameterizedMessage (message and parameters), > a SimpleMessage (message string only), and StructuredDataMessage (to support > RFC 5424), but all kinds of Message objects could be created. This makes it > easy for appenders and layouts because they just need to call > getFormattedMessage() to include that in the layout, or they can get to the > "message" via getMessageFormat() or the "parameters" via getParameters(). > >> > >> Ralph > >> > > > > I'd expect that parameterized log requests would end up packing the > format string and parameters into an object for evaluation in the extraction > phase. There are two different formatters in the Java library in addition > to the SLF4J formatter, so if you were interested in making sense of the > format string, you'd need to do an instanceof to determine which formatter > was being used. I'm thinking it is best just to rely on Object.toString() > to get the formatted string, If something in the stack wants to do > something funky with the message format string or parameters, they can use > instanceof to cast to a specific class. > > > > We'd likely end up with an ParameterizedMessage interface with the > getParameters() method and then concrete classes for the > SimpleFormatParameterizedMessage, MessageFormatParameterizedMessage, > FormatterParameterizedMessage, et al. I'd definitely like to stay using > Object for the message parameter in the core until there is a clear benefit > to being more restrictive. Should make it easier to support log4j's lack > of restriction on the message parameter if we don't have to repackage it as > a single parameter parameterized message, > > Well, I've finally begun doing some coding this weekend although I haven't > gotten awfully far. I am definitely going to be using the Message interface. > There were some lengthy discussions on the Logback list about this topic and > the problems using an Object introduces for applications like Lillith or > Chainsaw where the Object has to be passed to a remote system. Often > serialization fails miserably and toString often yields unsatisfying > results. It also requires the remote application to have the Classes in the > class path for the objects being sent to it to be able to deserialize the > events, which can be a pain for a general purpose logging reporting > application. > > Ralph > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
