Develop Reference

Is Apache Tomcat meant to be one install per hosted application?

I'm trying to understand the model that Apache Tomcat adheres to, and the documentation apparently doesn't make sense to me.
As I understand it, Tomcat is a server for hosting a wide variety of services - so it's pretty generic. I've got this application that I'm trying to understand how to host, and its main method of deployment appears to be as a Tomcat-hosted web service - the application is called Camunda (its on github). After going through the docs for Camunda, my Tomcat directory becomes absolutely filled with Camunda-related jars, and config files, etc. The docs say to just plop everything right into the Tomcat lib folder, conf folders, etc.
Most of my experience with other "platform" / "service" style host applications has been that the application itself, in this case Tomcat, stays pretty untouched in its own directory. Through config files, etc, it knows how to host whatever it needs to host.
In the case of Tomcat, it seems that it's customary to basically "pollute" the Tomcat dir with a bunch of libs for the hosted content?
This is why I made the title "is Tomcat meant to be one install per application", because for all intents and purposes once you host something in Tomcat the directory becomes so coupled with that something that the Tomcat directory IS that something.
Is this normal? Just looking for some clarification in perhaps other terms that the docs put it, because the docs don't seem to be very clear to me.
Here is a link to the install process that I am following and referring to: https://docs.camunda.org/manual/latest/installation/full/tomcat/manual/

It's been a while since I've used Tomcat, but not only is it not one-install-per-application, it's not even one-install-per-virtual-host.
Tomcat is (amongst other things) a servlet container. The directory layout and such for servlets was standardized in the Java Servlet Specification v2.2. You can download the latest servlet spec here.
The docs say to just plop everything right into the Tomcat lib folder, conf folders, etc.
Hopefully they're talking about the ones in a .war file or similar, or shared libs in the shared locations. You can put shared libraries in a location where they can be reused across applications (or even virtual hosts), which was probably useful back when disk space was more expensive, but these days I assume most people put the libs for an app in the /WEB-INF/lib directory in the application's .war file.
This page talks about the "directory" layout of a .war file (which is basically a .jar with a particular structure).
It's true that typically .war files are expanded into subdirectories of the Tomcat installation directory, but as indicated in the answer that Dan_Maff linked to in a comment, you can modify the server.xml file to have it look elsewhere instead.
You can install a webapp called Manager that helps with installing, activating, deactivating, and managing web apps via .war files. (There's also a Host Manager for managing virtual hosts.)
All that said, you certainly could do one application per Tomcat install if you wanted. You'd need a reverse proxy in front of it (Apache, Nginx, etc.) so the same port (e.g., 80) could be used for the external URL of the various applications, and you'd need to assign each Tomcat install its own internal port for the reverse proxy to talk to.

How to maintain JBoss Modules

Recently, I have had to port an app from Tomcat to Wildfly and I'm currently working on setting up the modules directory for Wildfly.
It took a little bit of learning, but I figured out how to set up Spring, ActiveMQ RA, and several other libs as modules. This is working, but it has me worried about future maintenance of the modules directory. I have had to craft the entire directory by hand and I am worried about having to do this for every new dependency that every new app needs.
What are the best practices for maintaining JBoss Modules? Is the modules directory put into some version control system like SVN to detect and propagate changes?
Lets say I need a new framework in my app. From my understanding I would need to download the jars, create a modules directory for the jars, and then repeat this process for each environment in which I need Wildfly. What happens when needing to do this while other apps are running? This seems extremely time consuming in the long run.
I feel like there is a much better way to do this that I am either not realizing or too green with JBoss to understand.
With Maven and a pom, its so simple to hook up to a local or remote repo, and have the entire directory built out and available everywhere automatically. I feel like there must be something similar for JBoss Modules.
At the heart of my question: How are others using JBoss Modules and maintaining it within a production environment? What resources should I read or utilize?
Thanks for your time.
Kevin

I'm also looking for a solution for this.
I have previously been in projects where the JBoss CLI is being used. But I dont like that. It adds complexity as the JBoss CLI scripts are something new that developers need to understand. Changes in files are easier to understand.
I'm thinking of this:
Put a directory in a git-repo that has the exact directory structure as JBoss version used.
standalone-full.xml is put in git-repo/jboss-eap-6.4/standalone/configuration/standalone-full.xml
module.xml-files is put in git-repo/jboss-eap-6.4/modules/system/layers/.../module.xml
Also a setup.sh that will:
Copy the files from the git-repo to the installation directory of JBoss.
Download any jar-files, needed for the modules.xml, from a configured Nexus server. And put them into correct modules-directory.
The benefits are:
No binary files in git.
Changes to configuration of JBoss can be tracked.
The setup can be a part of a bigger scripted setup of for developers or docker images...

How can I reuse a library in multiple WAR/EAR files deployed on an application server?

I'm currently working on an ebanking platform, so out customers are banks. To extend this platform, we develop our own 'xDK' (development kit) for 3rd party developers (usually the banks themselves).
When xDK is used as a dependency (via maven or gradle), it brings along a lot of transitive dependencies in order to work (~25MB). I was trying to think of solutions to make the dependency a bit lighter to use (given that it needs all of its dependencies) which in turn will promote having smaller, more focused services (not exactly micro-services but at least a step closer).
The current situation's benefit is that every service/project can use its own version of xDK and it doesn't have to update until it needs to. The problem is that it doesn't scale. If we assume 100 WAR files having xDK as a dependency, we create a 2.5GB overhead on the application server (even if they all use the same version).
I'll list two options I was thinking of, but I'd like to know if there are better solutions for this problem. Feel free to ask for more info. Thanks in advance.
Similar to JavaEE components (JPA, JAX-RS, ...), we'll have an 'api' dependency and the implementation. The projects will only declare the 'api' as a provided dependency while the implementation will be provided like so:
JBoss module
I haven't worked with other application servers. We (and our customers) only use JBoss EAP, so this might be a JBoss specific solution. We can create a JBoss module for xDK and then make every deployment depend on it via the JBoss deployment descriptor. The benefit is that we get rid of the multiple copies of the library, but we lose on version flexibility. This would mean that there needs to be some kind of governance on which version of xDK you code against in your service. Also, every time there is a breaking change, we'd need to update all services if we want to update the JBoss module to the latest version.
Bundle in an EAR
EARs allow multiple WAR files in them and also jars as libs. xDK will be an EAR dependency. Again, we have the same pros and cons as the previous solution. This solution is JBoss independent. However, it needs an extra build step to collect all the projects and bundle them, which might be annoying for out customers if they need to bundle their own services.

How about using the maven dependency scope of provided to declare that for the individual war files the jar file is provided outside of the war file, and then have another mechanism to inject the shared jar file into the application server?
c.f. https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html

Why does Java Web Start redownload jars from JBoss?

We just discovered that every time we restart JBoss, all of our Java Web Start clients redownload all of their jars, instead of reusing the cached jars, even if our application has not changed.
From what I've seen on the web, Java Web Start does an HTTP HEAD to decide whether or not to download a jar. So I ran HTTP HEAD on all jars in our application, and discovered that after restarting JBoss, the modified time of all the jars has changed!
Why is this, and how can I fix it? The jars inside of my application archives have not changed at all. As near as I can tell, JBoss uses the time of startup or time of deploy as the modified time. This is going to completely short-circuit Java Web Start's ability to use cached jars from previous runs, if I understand correctly.
We use JBoss 6, if that's an issue. Previously we used JBoss 4. I want to check to see if we had the problem under JBoss 4, but we now have so many dependencies on the newer JBoss that it is going to take some work to make that test happen.

Try deploying your application as an exploded web application instead of a WAR file.
That would prevent JBoss having to decompress the application and potentially mess up the modification dates.
You'll have to handle updates to your app in a way that preserves modification dates, e.g., rsync, but that might be easier than downgrading or patching JBoss.

It looks like VFSUtils isn't maintaining the lastModifiedDate of the file when it mounts the filesystem to the tmp directory on server startup. You could patch the copy methods in that class to try to set the timestamp of the new file based on the values from the physical file.
As a response to the comment by chubbard: the problem does not occur with Tomcat (tomcat 7.0.21 to be precise).

There is an issue (https://issues.jboss.org/browse/JBVFS-177) created about the VFSUtils.unzip() which does not preserve timestamps while deploying (still applicable to JBoss 6.1).
As the issue is related to the unzip method the solution of blahdiblah may indeed works.
Another way would be to use Java Web Start with a version based (Modification of the jnlp with versionEnabled and creation of a version.xml).

Java Servlet Deployment - To Embed or Not - Tomcat/Jetty

I have several webapps deployed to production. I have used Tomcat as my servlet engine for ~10 years now. I'm considering moving to embedding Jetty model from the deploy-a-war-into-Tomcat model.
These webapps are deployed over several servers and some of the are horizontally scaled (using nginx IP hash based partitioning).
I see some advantages:
I can configure my servlet engine for a particular webapp (instead of having a generic configuration for Tomcat which is running several different webapps)
It's easier to horizontally scale my webapp by running multiple Jetty instances (configured to listen on different ports) on the same host. I could also do this with Tomcat (and I have run multiple tomcat instance on the same host in the past), but I've moved to using Debian packages (.deb archives) for deployment and it's not as easy to run multiple Tomcats using this method.
My deployment package (.deb) is more "complete" at build time i.e. I don't have to be sure the Tomcat instance is configured correctly.
And disadvantages:
More instances of a servlet engine running on a server means more resources being used
I've never used Jetty. I don't think I have any Tomcat-specific stuff going on in my webapps, but I'm not sure.
My main concern is the amount of resources that Jetty will use. If I had one Tomcat instance running 4 webapps, what will the difference in resources (memory/processor) be with four Jetty instances running?
This question is probably too open-ended, but I'm curious to know if I'm overlooking something or if anybody has any experience moving from Tomcat to (embedded) Jetty.

The web container I've found easiest to embed in a jar file (and it is still a valid WAR too) is Winstone (http://winstone.sourceforge.net/).
Jenkins - http://jenkins-ci.org/ - use this container so it has been pretty stress-tested. Note that it is Servlet 2.4 only.

Well I think there is no direct answer;
I might not fully understand the ".deb" part as I'm not a debian freak :)
I prefer having an instance of tomcat with a number of configurations aka CATALINA_HOME folders where you may specify apps and ports running, so you can always have all your configs separately and change the tomcat instance if needed.
Also, see related post:
Jetty: To embed or not to embed?

I also was used to Tomcat, so in my new project I tried using Jetty to learn about it.
In an enterprise environment (where you have production / testing / development servers) I would stick to Tomcat, mainly because it helps you in getting to separate code from configuration files (now I am working in setting the conf files in a separate jar, because that way when I move changes from testing to production they do not have to manually update the jars that I'll pass to sysadmin).
Other issue is that it looks like that Jetty has changed ownership not so long ago, and looking for info often got me to the old version.
Apart from that, using Jetty is not that different from Tomcat; had to run a little through docs for finding where everything is, but structure is (as last what I have seen, I have not tried anything too complicated) more or less like Tomcat.