I've gotten to the point where I can have requests sent to IIS at http://anysiteonwin2kmachine.mydomain.com/specific_context_path handled by the webapp whose context path is /specific_context_path , but I'm at a loss as to how requests to a site's default page (index.jsp) should be set up among multiple different virtual IIS hosts. In other words, how to handle requests to http://specificvirtualsiteonwin2kmachine.mydomain.com or http://differentvirtualsiteonwin2kmachine.anotherdomain.com that implicitly map to index.jsp in the site's root directory and get IIS to let Tomcat handle them.
The main problem I'm seeing is that the whole ISAPI redirector mechanism seems to have no concept of virtual hosts, nor does it seem to have any mechanism for handling requests that don't involve a recognizable context path as part of the request sent to IIS. in other words, I can set up uriworkermap.properties with: /context1=$(default_worker) /context1/*=$(default_worker) /context2=$(default_worker) /context2/*=$(default_worker) and have requests sent to http://irrelevant_hostname.resolving_to_server_ip.net/context1 handled by the webapp whose context path is /context1, and have requests sent to http://irrelevant_hostname.resolving_to_server_ip.net/context2 handled by the webapp whose context path is /context2, but I see no straightforward way to have requests made to http://specific_site.hosted_on_myserver.com return one default jsp file associated with /context1 and have requests made to http://different_site.hosted_on_myserver.net return a (different) jsp file associated with /context2. even if adding /*.jsp=$(default_worker) to uriworkermap.properties worked (it didn't), there is still no apparent mechanism to associate *.jsp for one site with /context1/*.jsp and *.jsp for another site with /context2/*.jsp What seems to be missing is a mechanism to tell the ISAPI redirector, "requests made to http://firsthost/*.jsp should be proxied over to Tomcat as though they were really made to http://firsthost/context1/*.jsp", "requests made to http://secondhost/*.jsp should be proxied over to Tomcat as though they were really made to http://secondhost/context2/*.jsp" (with each handled by a separate Tomcat virtual host), with the existing uriworkermap scheme simply ADDING context paths to specific IIS virtual sites indicating requests that should simply be proxied over to Tomcat unchanged, like in this hypothetical properties file I'm envisioning: http://iis.virtual.host/*.jsp=http://tomcat.virtual.host/firstcontextpath http://www.iis.virtual.host/*.jsp=http://tomcat.virtual.host/firstcontextpat h http://iis.virtual.host/servlet/*=http://tomcat.virtual.host/servlet http://www.iis.virtual.host/servlet/*=http://tomcat.virtual.host/servlet http://iis.virtual.host/somecontext/*=http://tomcat.virtual.host/differentco ntext http://www.iis.virtual.host/somecontext/*=http://tomcat.virtual.host/differe ntcontext with other IIS virtual hosts corresponding to different tomcat virtual hosts: http://another.virtual.host/*.jsp=http://different.tomcat.virtualhost/its_co ntextpath http://another.virtual.host/struts/*=http://different.tomcat.virtualhost/str uts etc. In other words, providing a mechanism to identify requests that IIS needs to let Tomcat handle, but give Tomcat (or the redirector) enough information to intelligently handle requests that make sense to IIS, but not to Tomcat (without a little rewriting first). Actually, such a scheme is more or less how I kludged Apache to handle a similar situation a few months ago (when mod_jk was missing a feature I needed, and mod_webapp wasn't quite ready for real use) using mod_rewrite to proxy requests from Apache to Tomcat at port 8080 (dispensing with ajp altogether). It was ugly and inefficient, but it made the sites work and kept my boss happy... Am I overlooking an obvious solution, or is there really no good way to have Tomcat handle requests to a specific IIS virtual site's default index.jsp file, or to differentiate among virtual hosts at the Tomcat level as well as at the IIS level. Actually, if the scheme I mentioned above permitted context path substitution (so the Tomcat context path had no necessary path similarity to the request made to IIS), virtual hosts at the Tomcat level would be nice, but not necessary (http://first.com/servlet could be sent to Tomcat as http://localhost/first, http://second.com/servlet could be sent to Tomcat as http://localhost/second, etc.) -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>