tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Chaffee <g...@edamame.stinky.com>
Subject PoolTcpConnector and Logging
Date Thu, 15 Jun 2000 11:51:30 GMT

Just noticed the following change from Costin:


- small change in ServerConnector - removed the dependency on ContextManager,
now we use setServer(Object) and the protocol adapter can use it. That will
allow to use the tcp code outside tomcat.


Unfortunately, both the Connector and Endpoint now have lousy logging
behavior (System.out.println -- yechh!), and this change makes it
harder to correct.  They need a pointer to the context, or at least to
a Logger, in order to send error/log messages to the correct log file.

(They definitely need logging for the case when, e.g., an exception is
thrown before the serversocket returns from accept().  This happens
rarely, but often enough in a production server -- mine would run for
about 8 hours at ~100 hits/minute before crashing.)

How likely is it that this code will be used outside Tomcat?  If the
answer is "quite likely," I suggest we add a method setLogger() to the
ServerConnector interface, taking a tomcat.logging.Logger, so
non-tomcat clients at least have the option of well-defined logging.
Otherwise, I'll just check in what I have, which is to cast the
type-unsafe "server" object back to a ContextManager and use it.

By the way, this seems kind of hinky, changing
setContextManager(ContextManager) to setServer(Object). What problem
exactly is it trying to solve? Why not just leave it type-safe, and
deal with the null case sensibly in case of non-tomcat use?

 - Alex

-- 
Alex Chaffee                       mailto:alex@jguru.com
jGuru - Java News and FAQs         http://www.jguru.com/alex/
Creator of Gamelan                 http://www.gamelan.com/
Founder of Purple Technology       http://www.purpletech.com/
Curator of Stinky Art Collective   http://www.stinky.com/

Mime
View raw message