tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <cos...@costin.dnt.ro>
Subject Re: PoolTcpConnector and Logging
Date Thu, 15 Jun 2000 19:16:30 GMT
> - 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.

I think the Logger is a well-delimited and standalone component - or it
should be.

ContextManager just calls Logger.getLogger( "name"). It is not the
ContextManager that implements logging.

So the right solution is to just use the Logger component in connectors,
instead of passing a ContextManager when we want a logger.

> 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.

I think adding setLogger() is fine - if we plan to use Logger inside, then
we'll depend on it ( :-)

Please do so - I'm sorry I didn't had time to fix this when I did the
change.

The thread pool is great - I think it would be a smart decision to re-use
it. ( at least I plan to do use it whenever I need a TCP listener ).


> 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?

Reducing the component coupling, allow easier reusablity. The TCP code is
great, it shouldn't have deps on tomcat.

The "server" is not used by the the pool tcp listener - it is passed down
to the handler. ServerConnector can be used with something that is not a
servlet engine - then the "server" will be a FTPServer or anything else.

Costin 


Mime
View raw message