Mailet API logging and other changes

[Danny Angus <da...@apache.org>]

Noel, All,

Lets leave the Mailet logging, and other mailet API issues 'till after the
release.

There are a number of potential changes we need to discuss to the API and
James' implementation of it.
I'm prepared to review my opposition to advanced logging in the API, but not
right now.

d.


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Mailet API logging and other changes

["Peter M. Goldstein" <pe...@yahoo.com>]

Danny et al,

> Lets leave the Mailet logging, and other mailet API issues 'till after
the
> release.

+1

I concur.  Focusing on the release now (and getting it out) will help us
resolve these issues sooner.

--Peter




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Mailet API logging and other changes

["Noel J. Bergman" <no...@devtech.com>]

> Lets leave the Mailet logging, and other mailet API issues 'till after the
> release.

I wasn't planning to make any changes, other than reduce some debugging
output, until after the release.  Certainly not API changes!  I'm not
looking to cause a problem.  :-)

As things stand, I'm done.  Other than checking in some new mailet/matcher
code, I've got nothing on my plate for 2.1 release.  Which is good, since
Peter wants feature freeze tomorrow.  :-)

The logs are very important to me.  I maintain a monitor in the upper
righthand side of my workstation watching all of the James logs in
real-time.  If anything, I have added some useful logging information, e.g.,
when a socket times out now, we now log with whom it timed out.  OTOH, too
much tracing information, once the code works, can mask real problems.

One thing that I really want for the next release is the ability to
dynamically configure logging.  For example, if I suspect a problem in
handshaking, I want to be able to turn on debug for a protocol handler, and
then turn it off afterwards.  Right how I have to reboot to affect that
change.

> There are a number of potential changes we need to discuss to the API and
> James' implementation of it.

The storage interface is the other major area that comes to mind.

> I'm prepared to review my opposition to advanced logging in the API, but
not
> right now.

I agree.  API changes should all be post-2.1.

	--- Noel


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>