tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: Small refactoring in Http11Processor
Date Sat, 10 Sep 2005 04:31:31 GMT
Bill Barker wrote:
> ----- Original Message -----
> From: "Costin Manolache" <>
> To: <>
> Sent: Thursday, September 08, 2005 10:56 PM
> Subject: Small refactoring in Http11Processor
>>I have a small patch, spliting the JMX-dependent code in
>>Http11Processor, i.e.  the few lines of code dealing with the
>>registration of the thread pool and per thread data - and moving all
>>non-jmx code in a separate base class.
>>I know Tomcat5 is heavily dependent on JMX, but the connector can be
>>used in other containers, or it can be used standalone. This small
>>change won't affect any functionality on tomcat - all methods are used
>>only for intialization anyway, not in the critical path.
>>Please review and let me know if it's ok to commit the change.
> It seems that the only thing this patch does is to allow you to exclude
> jmx.jar, so it's usefulness seems very minimal :).  TC 3.3 & 4.1 already run
> very happily with the current code without JMX enabled.

True, it allows a smaller package. TC3.3 and 4.1 don't register the 
connector, so no JMX-related code is called, but it still requires 
jmx.jar to be around.

> Something better would be a refactor that would remove the duplicated code
> between Http11Processor and Http11AprProcessor (which one doesn't do :).

Yes, I've been thinking about this too :-), and also InternalAprBuffer 
and maybe add conditional compilation for the apr. But I didn't want to 
make the diff too big and risky.

> Of course, none of this is enough for me to veto your scratching an itch :).
>>Also, I would like to add another directory under j-t-c, with a build
>>file and few classes for a 'mini' experiment - i.e. using the connector
>>standalone, as a minimal http server, and also a target to build a
>>minimal servlet container as a single self-contained jar. We don't have
>>a sandbox, and j-t-c seems closest to that :-)
> I agree with Mladen that this would work better if you could wait a couple
> of weeks until we are up on SVN.

Ok, sounds good, I need to clean up the code anyway ( well, there are 
2-3 classes only and some build.xml ).


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message