james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter M. Goldstein" <peter_m_goldst...@yahoo.com>
Subject RE: Easy protocol logging
Date Tue, 03 Dec 2002 23:44:11 GMT


> It won't be quite the same. The other protocols work by reading one
> at a
> time and passing this to a command-specific method, where it is
> optionally logged, etc. IMAP uses a parser-style approach, where the
> is
> never read in it's entirety. This is important, because IMAP commands
> often
> can span multiple lines (eg when "literal" strings are used). Rather
> log
> the raw command, I think I'll construct a log message consisting of
> command name and parsed parameter values.

It's actually almost exactly the same.  I can say this with some
authority because I've done most of it.  :)  It's in the revision of
IMAP that I've got sitting on my box.  I will, as I mentioned before, be
checking it in shortly after 2.1 is out the door.  I, like all the other
committers working on 2.1, deferred further work on 3.0 until after 2.1
is out the door.

I'm well aware of the literal issue - you may notice that I mentioned it
you in my earlier message to you regarding IMAP.  It's one of the big
problems with the previous revision.  IMO, it needs to be fixed using a
builder pattern, not a parser.  A parser is essentially object-level
state unaware, while a builder is state-smart.

As far as logging only after parsing, I'd actually reconsider.  Part of
the reason you want to get the raw input as your starting point to your
process.  Logging only after parsing/building will of course hide errors
in your parser/builder.  It is common to log something approaching the
raw data (with appropriate filters for secure/overlong data) and then
have abbreviated log entries to describe the post-parse/build.


To unsubscribe, e-mail:   <mailto:james-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>

View raw message