tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: suggestion for XMLMapper/Setparent
Date Mon, 07 Aug 2000 20:48:19 GMT
> My need is for handler objects that get "started" after the
> adapters are started, they interface with the adapters and
> need running sockets and threadpool. The problem is that
> the initialisation of the interceptor happens before the
> start of the adapters. I would find it useful if handlers would
> receive a call after the start of the adapters.

Can be done, it's an useful notification.

I'm thinking of a more generic solution, where the interceptors can plug
themself into the right position in specific notification chains.
Something very similar with Apache 2.0 HOOKs. 

That means addInterceptor will just call an init() method instead of
adding the interceptor to the list of interceptors. The init() will then
add the interceptor to the desired hooks in a certain position ( FIRST,
LAST, BEGGINING, ENDING, etc ), using after( interceptor ) or just use the
config order.

Adapters will be simple interceptors ( that happen to start a tcp listener
and will be the last in the write() handlers and first in the
read() handelr list). That will simplify tomcat - a single
extension mechanism, and will allow adapters to change the request after
service() is called ( right now an adapter creates a request and call
service(), and have no further control ).

Anyway - I'm working on this, but it's very hard to find the time. XSL is
not easy, and I have a lot to do.


> One more question, I see lots of activity with changes
> to the logging. I was trying to add a timestamp to the
> log messages and found trying to subclass difficult, i.e.
> "final" log methods in contextmanager make me use
> TomcatLogger and prevent me from changing the log format.
> Any improvements possible there?
> regards
> Marcel
> >In general ContextManager is not supposed to change -
> >the normal extension mechanism is to use Interceptors.
> >Most of the time we deal with normal requests - if you have
> >a special case it would be very interesting to learn about it
> >and try to improve the architecture so we can handle it.
> >Either by extending Interceptors, providing more callbacks
> >or different semantics ( for example implement the same
> >mechanism as in apache hooks - it seems apache 2.0 is now
> >able to handle other protocols by using the same extension
> >mechansim we use ).
> >
> >Again - if extending CM works for now - don't change it,
> >maybe just make sure it works on 3.2.
> >
> >Costin
> >
> >
> >
> >
> >
> >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail:
> >For additional commands, e-mail:
> >
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message