Thanks for your patience Andre. I appreciate your careful, step by step description.

I tried a couple of things based on your information and a suggestion from Chris. I started by trying JKMount of /* to my worker and it did work, like I expected, but it also broke all the other apps that Apache was serving through PHP, which I expected. Christ suggested that I use JKMount /<context>/* but not knowing exactly how that would play when the context was ROOT I went ahead and installed the application at the /asaap3 context so the final JKMount entry was /asaap3/* . That works! And I understand why. All of the folders like /templates /scripts /images /stylesheets are off of the context so now the /asaap3/ASAAP pages have the correct url mapping. The anyhost/asaap3/ASAAP returns the correct path to anyhost/asaap3/images/bg_hdr_logo.gif

So you can not only find the correct page, but the correct images as well. The slightly longer URL isn't an issue. /asaap3/ASAAP vs /ASAAP isn't a problem.

Again, thanks for the patient explanations.

Pete


André Warnier wrote:
Pete Helgren wrote:
Thanks Andre. And, I DID carefully read your original post and I had some inkling that the problem had to do with context vs the JKMount directive. I had concluded that Apache had difficulty serving the images and I figured that the JKMount reference somehow was in the middle of it. References with /ASAAP were being rendered . Those without /ASAAP weren't rendering. What I am after is what is wrong with the current config in Apache or Tomcat that is breaking the references since another application works fine with that reference structure.

In the other example I posted that DOES work, the JKMount is /asaap3/ASAAP and the Tomcat context is asaap3 with servlet url being /asaap3/ASAAP. Not sure why the images in that case *are* being found .
Hi again.
Considering the last phrase above, and with all due respect, I think you still haven't really got it.
Let me try another way.
Forget that you have a Tomcat and an Apache, and consider things from the point of view of any browser which accesses a webserver, any webserver.

Step 1: you enter the url "http://anyhost/ASAAP";, and the browser in return receives a html page. Now, for the browser, "http://anyhost/ASAAP"; *is* the place it got this page from, and it is his "baseline" for this page. That is true no matter which "aliases", front-ends, back-ends, dynamic of static mechanisms have participated on the server side in producing that page in reality. The browser doesn't know that. It knows only that it asked for "http://anyhost/ASAAP";, and it got this page in return.

Step 2: in the received page, the browser finds a link to "images/myimage.gif". In the absence of any other information, the browser is going to request that item, from the same server, by doing the following : - it removes the last element of the URL (in this case "http://anyhost/ASAAP";) from which it received the current page.
In this case thus, it removes the "ASAAP", leaving "http://anyhost/";.
- then it adds the relative link to that. So it concatenates "http://anyhost/"; with "images/myimage.gif", giving "http://anyhost/images/myimage.gif";.
- then it requests that URL

Now the above is true for any browser, talking to any server, and there is nothing you can do about it. No amount of server configuration is going to chane the logic above, since it is the inherent logic of a browser.
So it will be so as long as :
a) either you modify the links in your pages so that they re-introduce this element "ASAAP/" that is stripped by the above operation b) or you find a way to make the browser "believe" that it did not get the first page above from "http://anyhost/ASAAP";, but from (for instance) "http://anyhost/ASAAP/index.html";.

Since (for good reasons, I agree with your reasons) you do not want to modify the references in your pages (a), then you must find a way to do (b).

Here is one way :
When the browser requests the URL "http://anyhost/ASAAP";, it should be told "that page does not exist (or has moved), please request "http://anyhost/ASAAP/index.jsp"; instead. Then the browser will do that, and request "http://anyhost/ASAAP/index.jsp";, and receive the original page. Now the browser knows that this page has been received from "http://anyhost/ASAAP/index.jsp";. So when it finds a relative link in that page, it is going to follow the same steps as above, but this time what it will remove will be the "index.jsp" at the end, and what will be left before adding the relative link will be "http://anyhost/ASAAP/";. So now it will request "http://anyhost/ASAAP/images/myimage.gif"; and bingo ! that is what your JkMount says to redirect to Tomcat, and bingo again ! Tomcat knows where that is (hopefully) and can return it.(*)

So you need, either at the Apache or at the Tomcat level, to make sure that in case someone requests "http://yourhost/ASAAP";, his browser gets a "redirect" response pointing to ""http://yourhost/ASAAP/index.jsp"; for example.

There are probably other possibilities based on a change of your application directory structure and/or mappings in Tomcat. But I cannot help you there, because I don't know what your Tomcat setup really is. Since trying the link "http://altusschools.k12.ok.us/ASAAP/"; (with a trailing "/") returns a /Tomcat/ 404 error, I guess that at this moment you have not "mapped" the URL "/ASAAP/" to your webapp. Maybe you should.

Can you give us the exact directory structure below the /webapps/ directory in your Tomcat ? It would help to know where the images and stylesheets really are with relation to the ROOT and ASAAP subdirectories.

(*) Note that from the look of it, Tomcat does not know where the URL "http://yourhost/ASAAP/images/myimage.gif"; is, and that is a problem.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to