Mladen Turk wrote:
But we don't wish to write something modular and unlimitedly extendable. Just the load-balancing-ajp13+ over tcp/ip connector, for Apache2. Having that in mind, we have APR, and 'almost' a finite set of requirements, without the need to 'think modular' or 'think cross-webserver'.
I understand this, and it is a good idea. I'm ok to drop "multi server" and "multiple protocols" or "extensible" and "jni".
The only point I strongly disagree is droping the "monitoring" and "runtime re-configuration". Tomcat is a dynamic server, people are using it to deploy and modify webapps all the time - editing httpd.conf and restarting the server on each change is not the right solution.
Also making any additional 'features' to the connector (like 'discovery'
etc.) would have to be made as such, and enabled during compile time, so
that the basic functionality remains as is. This means that we don't compile
everything and then use the config to either enable or disable features, but
rather make something like 'mpm concept' selectable at compile time.
Well, I also disagree with this :-), enabling/disabling discovery or other features should be done at runtime. I don't like too many ./configure options.
Seriously - if you take away the JMX and support for other servers - why not just use mod_jserv ?
No one prevents you of making mod_jmx that will allow entire Apache2 to be
maintainable trough JMX console, not only our module :).
Unfortunately - adding monitoring and runtime reconfiguration requires a certain design. Some parts of apache can be monitored, but not much ( certainly not the modules - unless you hack something and look in their private data structures ). Reconfiguration is even harder without having it in the design.
As I said, what you describe - basic protocol only and only apache - is already available in mod_jserv, it just needs porting to apache2. Why would you want to write another module doing the same thing ?
If you wish to write a good Apache2 module or IIS filter, they have to be different projects. Also being usable from admins point of view requires that the apache module is configurable trough httpd.conf, and IIS trough GUI. None of them uses JMX to configure the webserver thought.
None of the web servers support the dynamic webapp adding or clustering and all the feture that tomcat supports. I think monitoring and reconfiguration is a must feature for a servlet container, and that also means the web server connector should have basic support for it.
Think that the main problem is that we don't understand the JK2 code any more, and that the modularity combined with crosswebserver became an obstacle rather then a feature.
No problem, drop both ( and multiple protocol as well ). But don't drop features that actually matter.
Costin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
