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
catalina.properties.
Example simpler catalina.properties which could be used (I didn't test,
so maybe it doesn't work yet):
common.loader=${catalina.home}/lib,${catalina.home}/lib/*.jar
server.loader=
shared.loader=
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
