Curt Arnold wrote:
For the blob events I would build my own appender but if it was
derived from LoggingEvent and didn't overide or change any of the
functionality I would think it would work fine.
Why derive a class If it doesn't override or change functionality?
Sorry, I mean I wouldn't change
For the blob events I would build my own appender but if it was
derived from LoggingEvent and didn't overide or change any of the
functionality I would think it would work fine.
Why derive a class If it doesn't override or change functionality?
Even if it was transported, everything in the log
Curt Arnold wrote:
On Aug 27, 2004, at 1:21 PM, Jack Strohm wrote:
I was thinking about making a customized LoggingEvent (a BlobEvent?)
that supported what I need (blobs and properties with primitive data
types) and then my own Appender to transport it. I guess it wouldn't
be something anyone
On Aug 27, 2004, at 1:21 PM, Jack Strohm wrote:
I was thinking about making a customized LoggingEvent (a BlobEvent?)
that supported what I need (blobs and properties with primitive data
types) and then my own Appender to transport it. I guess it wouldn't
be something anyone else would want to
I was thinking about making a customized LoggingEvent (a BlobEvent?)
that supported what I need (blobs and properties with primitive data
types) and then my own Appender to transport it. I guess it wouldn't be
something anyone else would want to use, but I think it would get the
job done for
Every part in the chain believes that it can treat the messages as
text. A file appender, for example, would possibly apply a character
set encoding conversion before outputting a file. It would be unlikely
that your binary extraction code would work reliably if the user
reconfigured the outp
Ceki Gülcü wrote:
At 07:21 PM 8/27/2004, you wrote:
In my application I might be generating a very large number of log
events. Most times I don't want to know what's in the blob, but for
a small percentage of these messages I may decide that I want to
convert the blob into a string (or use some
At 07:21 PM 8/27/2004, you wrote:
In my application I might be generating a very large number of log
events. Most times I don't want to know what's in the blob, but for a
small percentage of these messages I may decide that I want to convert the
blob into a string (or use some viewer to display
In my application I might be generating a very large number of log
events. Most times I don't want to know what's in the blob, but for a
small percentage of these messages I may decide that I want to convert
the blob into a string (or use some viewer to display what is in the
blob). So while
At 07:12 PM 8/27/2004, you wrote:
I'm not really interested in logging any object, I'm more interested in
putting a blob into a logging event that I can extract later.
Don't you need to convert the blob into a string eventually? What good is a
logging API if you can't read its output? What am I m
I'm not really interested in logging any object, I'm more interested in
putting a blob into a logging event that I can extract later. It would
also be nice if the setProperty supported primitive data types (int,
long, float) without having to convert them into a string.
Ceki Gülcü wrote:
Log4
Log4j's ability to log any object relies on only one premise: any
java object can be transformed into a String. The Object class
contains a toString method and every java object is an instance of the
Object class. However, the toString() method does not always yield the
desired results, which is wh
12 matches
Mail list logo
