On Thu, 26 Jun 2003, Henri Gomez wrote: > Could we stop useless critics and flams and be more positives.
I'm sorry that you think it is useless to point out the specific areas where mod_jk and mod_jk2 are doing things wrong. > It's open source, and if you have objections, you're welcome to provide > fixes. To be honest, that isn't too appealing given the sad state of all the different connectors available and the extremely poor state of documentation about what is what and how things are supposed to work. But that is irrelevant, and doesn't change the validity of pointing out what things are problems and why. What is the release plan for mod_jk2? Is there any plan for making it production quality? There doesn't seem to be much happening with it. Is one better served to work on mod_jk instead and give up on mod_jk2? > > Never forget that mod_jk WAS DESIGNED to be cross web server compatible > and that's why some of the Apache functions are not used. mod_jk is the Apache specific module. The fact that there are other modules using some shared code that are specific to other webservers doesn't change anything. Web server specific plugins are the things that should tie tomcat in with the way the particular webserver works. It is quite sad to see how much worse webserver plugins have gotten since the days of mod_jserv. > BTW, on the Tomcat side, there is some URI checks since this problem > could also appears when using the built-in http connector. > > In the actual case the problem seems to be that Apache handle the jsp > directly since it didn't forward it to tomcat (probably because apache > and tomcat run on the same machine) The problem isn't that Apache doesn't forward it, the problem is that mod_jk doesn't forward it because it reimplements things that Apache can do for it a lot better and in a way that ensures it is compatible with everything else happening in the webserver. The same applies to other webservers. The mapping of what things should be passed to tomcat and what things shouldn't is a security critical area that can not be glossed over with a "ahh, we'll just make up our own way of doing things since it means we don't have to bother with the webserver". It is a plugin for the webserver, you have to bother with how the webserver works. It was a bad design decision to take the shortcut of trying to embed all the configuration within shared code and reuse it for every webserver. By describing the problems, I'm hoping that someone who does have the time right now can actually make one of the multitude of Apache --> tomcat connectors into something production quality without gaping security, performance, and stability issues. If not, then it will have to wait until I am at a point in my day job where we need to be deploying our applications and they need to actually work right and I'll worry about it then. Oh, for whoever is trying to actually make mod_jk work right... you may be able to do a "SetHandler jakarta-servlet" inside a Files section in a Directory section, not sure if it supports it properly or not, although that doesn't let you specify a specific worker. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
