-----Original Message----- From: Henri Gomez
We should first determine if Apache2 will have to monitor a service/system links to the various tomcats (in cluster configuration) to learn about real-time topology.
In fact, that is why I've pursued the .xml config over the current one. The main idea is to _internally_ have config tree (right now we don't have that). So that internal configuration tree will be populated either using directives in the native httpd.conf or reading server.xml stream from TC or from file.
Of course we should have somewhere in the new module the configuration tree in whatever native format we could imagine, apr_map maybe or apr_xml_tree if existing.
- the configuration should be in Apache's config file, rather than some complex properties file
+1
The general idea is to connect to TC and get the URI/VHOST topology, but we still need the 'intervene' directives for connector specific ones. How to make them simpler to use the JK and JK2?
Perhaps using something like:
<CoyoteWorker workerA> ...directives
</CoyoteWorker>
I agreed for this on worker configuration in httpd.conf.
And then:
<Files *.jsp> CoyoteUsesWorker workerA </Files>
ok.
We should also be able to handle :
<Location /myspecialurl>
CoyoteUsesWorker workerA
</Files>Something very familiar to Apache admins.
- it should work well with other modules (I guess if somehow it is accepted into the Apache codebase, it will be required)
That's why we should focus on Apache 2 only module.
Not sure I'm in favor of that (unless you meant dropping 1.3 module by that).
Of course, I want a module designed for Apache 2.x (2.0/2.1). Apache 1.3 could live with jk 1.2.x. IIS/NES/DOMINO could use jk 1.2 or jk2. No more code complexity to handle all the web-servers around, we should focus on Apache 2.x.
For example majors Linux distributions are now using Apache 2 instead of Apache 1.3. So Apache 2.x will be more and more used.
Without having a common codebase and API that can be used outside Apache2?
We should discuss what will be in the API, some will be only APR dependant, but of course many will be dependant of Apache 2.x, for examples Apache requests.
But we could see simple call, like :
int xxx_forward_simple_request(
xxx_worker_t *,
apr_pool_t * req_uri,
apr_pool_t * reply_data);int xxx_forward_simple_post_request(
xxx_worker_t *,
apr_pool_t * req_uri,
apr_pool_t * post_data,
apr_pool_t * reply_data);int xxx_forward_full_request(
xxx_worker_t *,
apr_pool_t * req_uri,
apr_table_t * headers,
apr_pool_t * post_data,
apr_pool_t * reply_data);In that case why not write only proxy_coyote for mod_proxy?
Since it will be nice to be able to be warned in mod_xxx from real-time topology updates, ie application down on one tomcat, new application on another tomcat, cluster updates...
- I think the protocol should be an extension of AJP/1.3
I proposed eons ago, AJP/1.3 extension, called AJP/1.4 and it could be a good candidate. In my idea we should start to write an APR based
AJP/1.4 library, which could be first used outside Apache 2 server for test and benchs purposes.
+1, but in contradiction with previous :). I would also like to see the gzip like extension to AJP/xx for lowering the data transfer.
It was proposed some times ago together with some light crypto to secure
apache - tomcat link when you're not in a secure network. All of these could be made optional in protocol negociation side of AJP/14...
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
