Mark,
On 12/14/25 2:58 PM, Mark Foley wrote:
On Sun Dec 14 10:18:41 2025 Christopher Schultz <[email protected]>
wrote:
Mark,
On 12/14/25 12:54 AM, Mark Foley wrote:
OK, I've given up on my initial approach to getting Apache Tomcat 10.1.13 to
run. I'e wiped the 10.1.13 directory and re-installed from the tarfile
(originally downloaded from tomcat.apache.org).
I added the following to context.xml:
<Resources allowLinking="true" />
Which context.xml did you modify?
$CATALINA_HOME/conf/context.xml
You should leave all files alone in the Tomcat installation. You should
only be changing files in your application.
Not sure what this means. I'm no Tomcat expert and I don't know where else I'd
change these configs.
You may or may not have a file in your application here:
META-INF/context.xml
If this file does not exist, you can create it and put just this in it:
<Context>
<Resources allowLinking="true" />
</Context>
You may choose to add other things as well. This allows you to deploy
this application with this configuration without changing the default
configuration for *all applications* which are deployed into the server.
Why? Because many of the jsp files are linked to a common source.
This is good information to have. Can you be very specific about that
symlinks you have? Not just where they point, but what their sources
are? Like /foo/bar/baz points to /a/b/c.
I've been doing this for years. For example, I have 20 hosted domains, all of
which are similar except for images, style sheets and displayed content stored
in the database. So, I have in $CATALINA_HOME/webapps/common/
-rw-r----- 1 mfoley mason 27378 2025-10-09 00:31 index.jsp
and in $CATALINA_HOME/webapps/horeb-wright3/
lrwxrwxrwx 1 mfoley mason 19 2022-05-23 02:46 index.jsp -> ../common/index.jsp
-rw-rw---- 1 mfoley mason 6583 2022-03-18 07:09 style.css
common is not deployed.
How are you preventing /common from being deployed? I might recommend
that you move this centralized stuff outside of webapps/ and put it
somewhere else, but it doesn't seen all that dangerous to do what you
have done. It can just cause confusion because of that
perhaps-unexpectedly-deployed non-application.
I haven't tried removing the allowLinking fom this iteration, but I recall
this being needed or symlinks like this don't work.
I agree that you require allowLinking; I'm just recommending that you
deploy that configuration in the application instead of editing server
global configuration. This makes upgrades easier because you don't have
to remember to edit that server configuration.
I removed from server.xml:
[snip]
I configured only one local hostname in server.xml:
<Host name="www.horeb-wright3.org" appBase="webapps"
unpackWARs="true" autoDeploy="true">
<Alias>horeb-wright3.org</Alias>
<Context path="" docBase="horeb-wright3" reloadable="false">
<WatchedResource>/WEB-INF/web.xml</WatchedResource>
<WatchedResource>/style.css</WatchedResource>
</Context>
</Host>
Not recommended, but okay. If you have <Context> in conf/server.xml and
also the file is in the webapps/ directory, then you will deploy the
application TWICE. Once on / (becasue you d <Context path="">, and once
on /horeb-wright3 because you have autoDeploy="true" and a directory
called webapps/horeb-wright3). This may be multiplying all of your error
messages by 2 in the log file.
It's not really dangerous, just confusing and wasteful.
I assume you're referring to the "autoDeploy" setting and not the whole
<Context>
tag. Yes, you mentioned the double deployment before, but I wanted to change as
little as possible just to get things running. I plan on setting these <Host>
autoDeploys to false later.
Actually, I *am* referring to the entire <Context> element. You can put
all of this into META-INF/context.xml and completely remove it from
conf/server.xml. Another opportunity to reduce the amount of
customization that needs to be done for a new version of Tomcat.
You will need to keep the WatchedResource for style.css. Tomcat should
already be watching WEB-INF/web.xml so I don't think you actually need that.
When you move the <Context> into META-INF/context.xml, you will need to
remove the "path" attribute: the name of the application WAR or
directory will dictate the context path.
If you can get away without putting <Context> in conf/server.xml, then I
would recommend that you remove it. If you want to deploy an application
on / then re-name the diretory horeb-wright3 to be ROOT (case-sensitive).
Again, I'm unclear here. I have 20 such directories like horeb-wright. I don't
know how I would specify docBase, etc. without the <Context> tag. I didn't
unilaterally put these in the server.xml file based on my own Tomcat
"expertise".
I got the info from help forums and other Tomcat advisory sources. If there is a
better way I'll be glad to try.
Yup, the better way is:
1. Move your <Context> element from conf/server.xml into each
application's META-INF/context.xml
2. Remove the "path" attribute from the <Context> element
3. Change the name of the application's WAR file or directory to the
name of the context path you want. You can see a more thorough
explanation here:
https://tomcat.apache.org/tomcat-10.1-doc/config/context.html#Naming I
recommend reading the following section as well.
I then started tomcat and got numerous errors in catalina.out.
Now, the jsp programs in webapps/horeb-wright3 were all created and running
under
apache 8.5.11. I do know that lots of javax stuff was replaced by jakarta. So,
if
I can get the right jakarta lib references into these jsp programs I might be
out
of the woods.
Tomcat can migrate your application for you, automatically. In the
Tomcat 10.1.x deployment, put your application into webapps-javaee/
instead of webapps/
Tomcat will auto-replace the Java EE imports with Jakarta EE imports
during the deployment.
Then you don't have to modify your original application just to test it
with Tomcat 10.1.
There is no webapps-javaee directory in the tarfile. Do I just create it, move
my JSPs to that directory, then start Tomcat?
Yup.
I see now that you will probably need that "common" directory as well.
I can try that later.
[snip]
OK, we hve a breakthrough!
I've removed and reinstalled Tomcat 10.1.13 for the 3rd time. I've kept the
same config files as described above except I've removed the <Host
name="horeb-wright"> tag completely, along with that directory in webapps. All
I left in webapps (other than the default installed folders) is common.
I put that "hello World!" index.jsp in webapps/common and started tomcat. It
started and I got the index.jsp page on a browser! Yay!
I then put in common's actual index.jsp and, after some tweaks with missing
includes (common is supposed to only hold symlink references, not be actually
deployed), and supplying some missing libraries, I got the REAL index.jsp to
run.
Next, I copied all the files for horeb-wright from the 8.5.11 directory to
webapps, which includes the lhink to ../common/index.jsp, and that loaded OK!
I then copied over all the other webapps from 8.5.11/webapps, added their <Host>
tags to server.xml, and they also loaded and ran. So, whew! it is working!
Can you show *two* of those <Host> entries to us? I wonder if you are
setting up a situation where you have a ton of deployments for a
relatively small number of applications. This can compound the
confusion, errors and warnings, etc.
I went ahead and changed the autoDeploy="true" to "false" in server.xml, and
that seemed to work too.
So far, I have not run into any issues with javax vs jakarta, but if you can
answer my quetion on that auto-convert I'll be ready to try that.
I know I have a few programs using an obsolete org.apache.commons.fileupload
class, but this mailList helped me with that 3 years ago, so I think I can
figure
that out.
I don't know what I did differently on this successful round. Maybe I had
deleted something needful (I did remove the default webapps folders, ROOT, etc.
I did not do so this time). The configs, webapps, and the like are the same as
in my previous post (as far as I know).
If you can provide some feedback on my questions on your comments avobe, I think
we can stick a fork in this one.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
