peter royal wrote:
On Mar 4, 2006, at 9:37 AM, Michael Link wrote:
I think this concept would be orthogonal to the Filter-Chain concept;
instead of a chain you have decorator of the filter. And life-cycle
management still works as designed except in the cases where the
user/container explicitly manages the IoFilter. Doesn't solve the
current deadlock problem in ThreadPoolFilter but perhaps adds
something to the discussion about automatic/manual life-cycle
management.
I like this! But I'd invert it -- the behavior of the IoFilterLCM
could be a decorator.. If it is desired for an IoFilter to be
destroyed when not in use, then prior to adding to the template chain,
it would be wrapped in a decorator.
-pete
--(peter.royal|osi)@pobox.com - http://fotap.org/~osi
From a user point-of-view it's easier to let MINA do all of the LCM
most of the time. So the decorator should only be necessary when
user-defined LCM is needed. In the whole I think the init-destroy
discussion currently only affects the ThreadPoolFilter because it's the
only one with shared resources. Perhaps the ThreadPoolFilter should be
split up in two objects, one for the filter implementation and one for
the pool implementation (I think this was discussed before).
FilterChain
|
ThreadPoolFilter -> ThreadPool (TPF uses TP-Interface which can have
different implementations L-F-Impl, Java5-Impl ...)
|
LoggingFilter
|
....
Mike
