I think I understand what you're trying to say and I wouldn't like to introduce a piece of code that fixes one thing and breaks a bunch of them (load balancing, virtual serving etc.).
Let me submit this analysis. The static, local (to Apache) copy of index.jsp (or whatever other file) will get picked up (i.e. its existence will be recognised by mod_dir) only if: - it actually exists (otherwise r->finfo.filetype will be 0) - DirectoryIndex is set to pick the file up So, if you have a load balancing scenario or virtual serving, don't use DirectoryIndex and/or don't put files in you local file system, but use other mechanisms (precompiled JSP's or let Tomcat pick the default file up) for that. It is unrealistic to expect from Apache to pick up virtual files, invisible to it from within the file system. And since it's Apache that's doing mod_dir here, I don't think that we should go very far into virtual land. One other thing also. In the actual code, the file to be picked up is now set as an absolute file name. However, if I do this at the end of jk_map_to_storage(): -------------------------- r->filename = (char *)apr_filename_of_pathname(r->uri); -------------------------- (i.e. make the file what it used to be, just make r->finfo.filetype = 1), the whole thing still works (minus the aliases, which is just a plain bug). So, jk_handler() is making its own choice about what file (physical or virtual) is going to get served, it doesn't rely on info in r->filename at all. The only difference is that mod_dir gets that 1 set in jk_map_to_storage() (done in the 'what if' sub request of mod_dir) and then engages a real request a bit earlier. This is a request with handler type "jakarta-servlet" and goes through mod_jk again. So, I'm not sure that things would get broken anyway. But, it's a possibility, in which case just don't use DirectoryIndex, since it doesn't make sense anyway. The old code (in mod_jk for Apache2 and mod_jk2 for Apache2) breaks DirectoryIndex as compared to Apache 1.3.x and mod_jk 1.x. We can make a few choices here: - fix aliasing in the patch and explain to people how it really works - let the patch into mod_jk 1.2.0, but not 2.x - kick the patch out of both - kick the patch out of both and change how 1.3.x/1.x combo works too and then let people know about it I can live with any of the above since I fully control my own environment and can adjust accordingly. Bojan On Sun, 2002-07-21 at 21:20, Mladen Turk wrote: > Just to prove the concept put the following in your workers2.properties > > [uri:/*.jsp] > info=Extension mapping > > And then try your patches. > > We are obviously having some concept misunderstanding. I don't say that > I'm happy with the current implementation of mod_jk2 and how it deals > with the rewriting, but I think we shouldn't try to clarify that a bit. > The problem is far more complex then it may look. > > We have a two situations, with the TC on the same box as apache, and on > the remote one. Well, that is only the partially correct, cause the load > balancing brakes that. > > So what we have is the following for example > > /someapp/ > ------>/somelocation1/someapp/ > ------>/somelocation2/someapp/ > ------>10.0.0.1/someapp/ > ------>10.0.0.2/someapp/ > ...etc > > Basically this is something like a reverse proxy situation. > All that has to be mapped inside the apache's directory tree at the > /opt/apache2 but can go to the any physical location above, or any > virtual one. > You can serve the static mime-type context only from the first two > cases. The Load balancer have no idea about the fact where the app is > located (local or remote), so the .gif will get served according to the > lb state, not its potential context performance, but that is another > story. > > Your patches brakes the entire lb concept, and that is the reason that I > don't like it. Its not the problem with the static context (probably > it's a performance gain), but the default index.jsp will get served only > from the local TC no matter what the lb thinks about that. He may mark > the 10.0.0.2 as a active env, and you will map that to a local > /somelocation1. > > What we need IMO is that lb informs the map_to_storage whether we are > serving local or remote, so that we don't force the local context all > the time if present. > > > > > I mentioned in the previous e-mails that aliases have not > > been covered with this patch at all (that's why Mark's having > > problems with them). They would have to be dealt with as well. > > > > As I said (perhaps I'm totally wrong) you shouldn't suppose that the > context is inside the local file system. It has nothing to do with the > static context serving, and you don't have enough info to decide where > the context is situated. > > My suggestion are: > > 1. Let see how can we get the info whether the context is from local or > remote storage (and then use the map_to_storage accordingly) > 2. Let the TC decide what the default served file will be for a > particular uri (Dropping the entire DirectoryIndex fuzziness) > 3. See how to enable the DirectoryRoot mapping > > MT. > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>