Ray Holme wrote:
Hmm . . . . Lots of speculation here. How are the files referenced in
your application? It seems that if the physical files are available,
then the application works fine. If the physical files are not
available, then the database has problems (firebird under xinetd,
perhaps?) and you get 404 errors. Does the application scan a directory
and populate the database on startup? Does the database need to know
where the files are? Does the database need read access to the files?
I have spent the night thinking about this. As I said before, these files have
NOTHING to do with the database (located elsewhere and outside of the webapp,
of course).
They are accessed by either HTTPD or Apache/Tomcat (WHICH?). And therein may be
the rub. Perhaps if the file is accessed by Apache/Tomcat (port 8080), they would
be fine. Perhaps if HTTPD (port 80) tries to get them using
/var/www/html/myApplication (a symbolic link to /opt/apache/webapps/MyApplication)
it fails. If this makes sense (and it might), then it depends on how the file is
going to be picked up - is there any write-up to figure out how this httpd VS
apache/tomcat link works (I have no idea what modjk.so does except pass things
back and forth between the two :: totally needed in Linux but not on a deployed
application in MS-XP using port 8080 - perhaps exclusively without using port
80). If this does NOT make sense, then making the application run as tomcat (not
root) does not make sense for improving this particular situation (agreed that I
should do this and will immediately, but root -> tomcat should not change the
link behavior - in any
of the three scenarios (link, alias, virtual directory)).
Once I get the tomcat user to run everrything, I will try again and post the
results.
I believe that you may be confused by this "Tomcat user" aspect of things, and you should
maybe look at the issue from the other end.
The application (presumably) generates HTML pages, which are sent to a browser.
In these pages, there are links to the "files" (images or whatever).
What do those links look like in the HTML received by the browser ? (use : "view page
source" or "copy link location").
And (to compare), what does a link look like, which points to some "executable" part of
the application (a real java webapp servlet/jsp page) ?
Next, tell us how the browser accesses the application. Which hostname/port is
it using ?
And which server-side software answers to such links ? (does this link directly to Tomcat,
or to Apache httpd which then forwards some (or all) requests to Tomcat ?)
Even if this is not really a Tomcat issue, people on this list may be able/willing to help
you, but you have to provide precise and comprehensive information first, so that they do
not have the impression of wasting their time following dead-ends.
Note that in any case, it is almost always a bad idea to allow an Apache httpd front-end
to access any part of a Tomcat webapps directory directly (or via filesystem links).
That is because then, it can completely bypass the Tomcat builtin access security
mechanisms. (It is also not portable if some day you decide to run Apache httpd and Tomcat
on separate hosts).
But it is certainly possible - and perhaps much easier in your case - to have Apache httpd
only forward *some* links to Tomcat, and serve other documents (like your files or images)
directly from within the Apache httpd DocumentRoot file structure.
Which would remove the need to have these files hosted under the Tomcat webapps dir, which
seems to be your ultimate goal if I have followed this correctly.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
