tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <>
Subject Re: Refactorings
Date Tue, 28 Mar 2006 12:05:12 GMT
Yoav Shapira wrote:
> Yeah.  And in general remaining a pure Java scenario for those who
> don't want the APR dependency.

Sure, I have no problem with that (I do have a problem with that in my 
branch, though, as I think people who are doing real production web 
stuff right now are ok with an APR dependency, as long as it has some 
benefits). I added back support for the Java HTTP connector (minus 
HTTPS) for development purposes.

As I said, I have no intention of doing any refactoring to this, or use 
any of the refactorings that may occur in the Tomcat 6 branch. My post 
was to show a refactoring method where I first modified the endpoints to 
look similar before extracting a superclass, by opposition to extracting 
a superclass first and then try to make the endpoints fit that model.

>> - the "classes" folders allow patching (which of course may not be that
>>> useful)
>> Did we ever did such a patch in the last 5 years ? How would it interact
>> with
>> package sealing ? etc.
> I routinely see users and companies using the classes folders for
> patches not integrated into the Tomcat distro and for trying out
> little enhancements, bug fixes, etc.  I use it myself sometimes for
> testing patches and bug fixes before I commit them.  It's a handy
> tool.

Yes. Maybe we could use a small trick to provide the same functionality 
with fewer folders. For example, JBoss puts most of its folders on the 
classpath (this includes the folders where the JARs are located, the 
"conf" folders, etc). I don't see any reason to change the internal 
Catalina code, as the classloaders are easily configurable using

Example simpler which could be used (I didn't test, 
so maybe it doesn't work yet):



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

View raw message