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
