It is difficult to dynamically discover the pattern and would be a pain in
the ass to have to specify the pattern to view a log. A fixed delimiter
would help. This could be configurable and specified in a props file, so
the pattern set up and viewing could be built to use the same character. . .
-----Original Message-----
From: Anders Kristensen [mailto:[EMAIL PROTECTED]]
Sent: Saturday, May 26, 2001 5:22 PM
To: LOG4J Developers Mailing List
Subject: Re: log viewer
Well, under the scheme I was describing you can insert whatever
delimiters you like simply by having them as literal text in the
conversion pattern. I don't see what's gained by enforcing one
particular delimiter. And, BTW, "~" can, as pretty much any other
delimiter one might choose, occur within %m, %t, %c, %p (with custom
priorities), etc. Some assumptions or restrictions are probably needed
in any scheme.
Anders
Amarnath wrote:
>
> I thinks better to add some delimiters in the output layout format like,
>
> Layout Format : [%t] %-5p - %c{2}: %m%n
> Ouput : ~[main] ~INFO - ~com.foo : ~This is Amarnath
>
> This we can easily split the output and display in GUI.
> for that u have to override the appenders with append() method, that ur
> layout format should inserted like this : ~[%t] ~%-5p - ~%c{2}: ~%m%n
>
> i think we can easily display with this format.
>
> this will help to view log messages in GUI
>
> _____________________________________ Amarnath P " try agian and again
till
> you get SUCCEEDED"
> ----- Original Message -----
> From: "Anders Kristensen" <[EMAIL PROTECTED]>
> To: "LOG4J Developers Mailing List" <[EMAIL PROTECTED]>
> Sent: Friday, May 25, 2001 8:25 PM
> Subject: Re: log viewer
>
> > Some random thoughts...
> >
> > I agree that relying on XML would be a big limitation on the viewers
> > usefulnes. Maybe it would be possible to have a parser which takes as
> > argument a description of the log format (single line per entry), and
> > then parses an input stream according to that format, ignoring lines
> > which doesn't match.
> >
> > The format description could simply be the PatternLayout conversion
> > pattern. For example, a pattern like "[%t] %-5p - %c{2}: %m%n"
> > unambigously specifies how to parse a String, I think. Of course it's
> > possible to write conversion patterns which doesn't have that property,
> > but that can be dealt with.
> >
> > The most important case where log entries span multiple lines (XML
> > formatted log files not included) would be when exceptions are logged.
> > Most (all?) log4j appenders which log exceptions do so after logging the
> > message it relates to. A really clever parser might look ahead to see if
> > a stack trace was following a line, and if so, parse it (maybe just as
> > one String) and pass it up to the viewer along with the log entry it
> > "belongs to".
> >
> > Anders
> >
> >
> > Aaron Smuts wrote:
> > >
> > > xml would boat a log file and put too much overhead on the system.
I'd
> > > rather parse a text file without a bumch of tags. It would be nice to
> view
> > > it as plain text without a xml parsing layer and to be able to view in
a
> > > browser. I only use xml in last resort situations.
> > >
> > > -----Original Message-----
> > > From: Jim Moore [mailto:[EMAIL PROTECTED]]
> > > Sent: Thursday, May 24, 2001 11:17 PM
> > > To: 'LOG4J Developers Mailing List'
> > > Subject: RE: log viewer
> > >
> > > Suggestion: If you spit everything out in XML with a "Thou shalt use
> this
> > > DTD to use this viewer" then you don't have to worry about various
> formats
> > > and you can use any of the awesome XML tools (eg. Xerces, Cocoon,
etc.)
> to
> > > transform it any way you like easily. Transformations from XML are so
> > > simple that it even works if your appender is an XML file and you use
a
> > > simple "tail" type program that transforms the elements to something
> more
> > > appropriate for a human to watch.
> > >
> > > -----Original Message-----
> > > From: Aaron Smuts [mailto:[EMAIL PROTECTED]]
> > > Sent: Thursday, May 24, 2001 10:32 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: log viewer
> > >
> > > I built into a logger that I was using for a while ( one similar to
> log4j )
> > > a nice servlet log viewer and sorter. Weblogic also has a nice log
> viewing
> > > interface. If log4j had a good, clean log viewer that could sort and
> > > filter, it would have every feature possible. The difficulty is in
> making a
> > > sorter that would be able to read multiple formats. Some set of
format
> tags
> > > could be identified for rough date, category and level sorting. A
> browser
> > > interface would be ideal. I'm thinking about having my team build one
> > > along witht he jms-rendezvous appender ). It would be a nice
additon.
> . .
> > >
> > > Aaron
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
