I think I found a good way to implement the previous proposal, it should solve the short term problem and allow later development. The plan is: - start by fixing jk_uri_worker_map to support the virtual host ( it's one of the biggest missing points ). - extend the jk_map to support a bit more advanced properties, where instead of name=value we'll have "tuples" ( host:uri=worker ). - replace the 3 config generators with a single one, generating _all_ the mappings known to the server ( exactly the information that is used in SimpleMapper ), using the easy-to-parse format. - The workers.properties will be "pre-cooked", i.e. the goal is to minimize the processing on the C side. The format I have in mind right now is a simple extension to the name=value, and I would go one more step and add: exact:host:uri=worker:contextPath:servlet prefix:.... security:host:uri=... welcome:host:context=index.jsp Etc. On the first stage, most information will be ignored. It's _extremely_ difficult to support all the web.xml configurations, for example I don't think it's even possible to support different welcome files based on context ( it is eventually possible in apache - but I couldn't find a way in NES or IIS ). So we'll start with just redirecting all the requests ( and later, when the jasper's extensions will be added, the static files will go back to beeing served by apache ). What I want is to have _all_ mapping info available, even if it'll not be used right away. A next step would be to implement the mapping alghoritm used in SimpleMapper and AccessInterceptor - in C, part of uri_worker_map. Then static files will stay with apache from beginning ( but still we'll duplicate the native server mapping ). A third step would be to try again to generate native rules - apache2 supports API access to configuration. The "tuple" style for the config file will also help a lot in implementing the Ajp14, but for now I think extending uri_worker_map and adding the rest of the infrastructure is more important. Regarding 'manual mode': in the handler we must check if worker is null, and call uri_worker_map ( or use the "default" worker ). That would allow native server config that sets the handler. I'm not sure having more than a protocol in use is a common case ( even for loadbalancing, the default will be the lb worker - so we can still use the default ). On another front, we should reduce the configs in the server, and use the worker.properties and urimap.properties for most configurations ( i.e. common for all servers ) ( debug, log file, etc ) Costin
