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/catalina.properties.
I found some vague references to this in Tomcat docs, but nothing
concrete. Can you offer actual specifics on how to:
a) Modify catalina.properties 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
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.
Many thanks in advance for your input
Best Regards
Jamie
