tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: multi-tenant web app
Date Thu, 18 Apr 2013 16:17:03 GMT
Hash: SHA256


On 4/18/13 6:42 AM, Jamie wrote:
> Chris / Tomcat Users
>> This can already be done with the common or shared classloaders
>> (which were removed by default because nobody could make head or
>> tail of how to use them properly). They can be trivially
>> re-enabled using conf/
> I found some vague references to this in Tomcat docs, but nothing 
> concrete. Can you offer actual specifics on how to:
> a) Modify file to get all web apps to run under
> the same class loader

This behavior (all in one ClassLoader) would break the servlet spec:
each webapp requires a separate ClassLoader.

What you can do is re-enable the "shared" and "common" ClassLoaders,
and move your libraries into the appropriate directories. Read the
Tomcat Users' Guide under "Class Loading" and then read the comments
in conf/

> b) (if possible) Modify Tomcat's context configuration such that 
> multiple instances of a web app can be loaded from the same class
> files, libs and resources on disk

You can do this via ClassLoader games described above.

Note that things like logging won't work the way you want them to
(e.g. one log file per tenant) if you throw the logging libraries into
the shared ClassLoader.

> I am aware that there are alot of issues to consider, esp. when it
> comes to Java's dreaded class loader architecture.

I don't dread anything about Java's ClassLoader architecture. I quite
like the way it operates, though I would prefer if a SecurityManager
could be configured to treat different ClassLoaders in different ways,
rather than having to bless JAR files individually.

> There must be a better way. We could:
> 1) try to configure Tomcat with its mysterious (largely
> undocumented) multi tenant features

Other than playing ClassLoader games, Tomcat does not have any
multi-tenant features, mysterious or otherwise.

> 2) Modify the Tomcat source code to do what we want (problem here
> is it will take time for us to understand Tomcat's complex code
> base)

If you propose some good ideas, you might not have to write anything.

> 3) Build the multi-tenant capability into our app.
> Despite what you say, I still feel, logically, the app server
> should provide the multi-tenant capability. It would provide huge
> savings for developers under pressure to move their applications to
> the cloud.

Are you primarily interested in reducing the amount of memory required
to run your webapps? java.lang.Class objects don't take up much space
in memory... it's the objects your webapp creates that are going to be
the bulky stuff. So, if you want to run with 50 tenants, you'll need
50 times as much RAM for working-heap, regardless of the number of
webapps deployed.

>> 2. Any shared data in the libraries themselves can allow
>> information to leak from one tenant to another.
> Yes, of course this is a risk we take.

I think this is what it ultimately likely to ruin everything.

>> So, your webapp itself does have to have some measure of
>> multi-tenancy awareness. Multi-tenancy isn't just something you
>> can slip-in at the
> infrastructure-level.
> I agree that the issues can be complex. However,  some of the
> complexity comes about because Tomcat was inherently designed
> support running different web applications on the same server. The
> reality is that in today's world, a bigger use case is to want to
> run multiple instances of the same app in a very light weight,
> scalable and easy-to-manage fashion.

Amazon Elastic Beanstalk?

- -chris
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message