> > What "scratchpad thread pool"? James uses Thread pool management
provided
> > by Excalibur. Are you proposing that we replace their thread management
> > code with new classes derived from Doug Lea's library?
> I think we should [replace Excalibur's thread management
> with code derived from util.concurrent]. Replacing thread
> pool abstraction should be straight forward.
I don't disagree that util.concurrent is good code, and there are some
things that I prefer in it to the analogous Avalon code from Excalibur, but
we only found one bug in their code, which (a) we've worked around and, (b)
they've fixed in their CVS.
AFAIK, replacing the abstraction could require decoupling the handler
classes entirely from Avalon Frameworks. Since the Avalon folks are working
directly with Doug Lea, and tracking JSR 166, with the intent of using the
result of JSR 166 in some future version of the Avalon code, why would we
want to decouple from Avalon now?
> Thread pool code was part of scratchpad where the Avalon folks had useful
> but not fully qualified code. It looks like it has been moved to not sure
> where.
It is part of Avalon-Excalibur.
> > The ThreadPool and MimeMessageInputStream changes *are*
> > independent of the Watchdog / Scheduler issue.
> Had to wade through a alot of code, so could not easily
> separate. Thanks for pointing out.
You're welcome.
--- Noel
--
To unsubscribe, e-mail: <mailto:james-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@;jakarta.apache.org>
