Costin Manolache wrote:
Henri Gomez wrote:
Costin Manolache wrote:
Mladen Turk wrote:
Of course, no one is forced to participate in development, but everyone is
welcome. The only question is do we have enough juice to make it official.
AFICT, Remy, Henri and myself are in favor.
But frankly I see no reason for someone to object, cause it's open source
after all, and it doesn't break nothing that already exists.
I'm not in favor, quite the contrary.
And I thing there are reasons to object - "doesn't break anthing that exists" is not the only criteria used in apache. "Is it the best solution ?" can be used sometimes.
Well I've got more than one reason to object to current jk2 and jk.
This is not about objecting to current jk and jk2. They are where they are because of some design and requirement errors. The whole point is to avoid this. It should be obvious that adding important features as an after-tough and starting with "just code that doesn't break" instead of a sound requirements and design will likely lead to the same spaghetti and mess in the long run.
I said that some known Tomcat instances, Remy asked us to avoid the old jk/jk2 naming, are set in Apache 2 by default, but nothing prevent us to add new instance dynamically, via ajp_status or mod_status or whatever (may be even via AJP/1.4).
Nothing prevented us to add any feature to mod_jk.x either.
3 years ago we didn't know all those requirements - few people were thinking at that time that tomcat will be used in "allways on" configurations.
And if "dynamic config" is not on the list - then it won't solve the problem for people who really need apache+tomcat, i.e. many large sites with uptime requirements. Why confuse the people with yet another connector - and what hope can we have it will not have the same fate as mod_webapp ?
I'm handling sites requiring this kind of requirement and it's high on my mod_ajp features wish list. When you operate sites which works 24/24 and 7/7 and need to add horse power, it's a nightmare to have to wait some period in the night to make the Apache server update and restart.
Also admins may want to add some power for a short period of time, so adding and removing such instances should be easy and quick.
Ok, so what is the plan to support this in mod_ajp ? Is this on the list of requirements - and for that matters, what is the list ? If it is, again, how do you plan to support it ? It's not a trivial issue, reconfiguration is very hard - and most likely to create a lot of spaghetti.
It's not funny how we allways refuse to learn from our mistakes, and periodically repeat them
Well I'd like to resume the mod_ajp goal :
- an APR/Apache 2 specific module (no more mess with #ifdef for 30 differents OS, we're in 2004).
- extract ajp stuff and put it in an ajp library, which could be used outside within the Apache 2.0 module, used by proxy_ajp and of course in others applications, ie ajp-bench.
- Study what has been done in mod_proxy to follow the start of art in Apache 2.x dev and make sure we could works with others AP2 modules.
- Add/Remove/Update of Tomcat instances, and allow to attach/map them to URI and LB instances.
What about adding/updating of webapps ? Is this a feature that will never be added ( because if it will be and it is not part of the design - then we're back to spaghetti )
Well if you recall my AJP/1.4 proposal it was on my wish-list :
Adding/Removing/Updating a webapp on a tomcat instance is on the features list.
I think it should be done by adding/removing the mapping between Apache and the particular Tomcat instance.
Costin will probably mention JMX/CMX support, but I think this is something so important that it should be in HTTPD-dev and not only in mod_ajp.
JMX is just a mean to an end. The goal is dynamic configuration ( i.e. without restart ).
Yes, it should be more available in httpd-dev ( they do have some with .htaccess, etc ), but we have few clear use cases they don't. Well - dynamic add/remove of webapps is quite trivial in apache, you can add cgis/php/etc without restarting the server even today.
JMX/CMX will be a great interest for all HTTPD modules, to update for examples Location/Directory....
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
