tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jamie <>
Subject Re: multi-tenant web app
Date Thu, 18 Apr 2013 10:42:42 GMT
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

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
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

I am aware that there are alot of issues to consider, esp. when it comes 
to Java's dreaded class loader architecture. I certainly didn't mean to 
give you the impression that I thought it was as simple as flicking a 
switch. We in fact wrote an entire management application with 
sophisticated GUI that integrates with Tomcat's API's to support multi 
instance deployment. The solution works. In some cases, we have as many 
as eighty different web apps running under one server. The problem is we 
don't like our current solution. It is uses up more resources than we 
like. Furthermore, the proliferation of web apps introduces a management 
headache. When there are a large number web apps, the Tomcat server also 
takes an age to start.

There must be a better way. We could:

1) try to configure Tomcat with its mysterious (largely undocumented) 
multi tenant features
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)
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.

 >Note however that there are a whole slew of potential severe problems
 >with simply playing ClassLoader games:

 >1. You likely can't have a different version of library X for one
 >single tenant (you can put it into WEB-INF/lib but it might not be
 >visible from the right place and/or might conflict badly with the
 >shared library)

Well, if you will permit me to apply some creative thinking here, I 
could envision a situation where there was an xml file with any number 
of virtual contexts organized into groups. Each group could refer to a 
specific version of the web app on disk.  Tomcat would load each group 
of virtual contexts into a separate class loader. All virtual contexts 
in the same group would be loaded into the same class loader. Using this 
mechanism, the number of web apps on disk would be limited to the number 
of versions of the web app. Furthermore, it would be possible to run as 
many instances of each version as needed in a lightweight fashion.

 >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.

 >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 

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.

Many thanks in advance for your input

Best Regards


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message