-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Jamie,
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/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 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/catalina.properties. > 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRcBx/AAoJEBzwKT+lPKRYv9sP/iNtyzcrExKwbE26+RsyROZk odMSzwwpJgZnzVpDI2XKqRYMEppHUB1pDbqj7tkSrc2wOaSBH2nC81KO5/PdHzZ5 lofC92D8ST/PQhhSuPKQxVCBOkChqdVpj9A0eDLNlDHKIjffeLsDYjg++NU55s8V uvDjRjhtEdbixgflfrm9qUV9TnrfEIJHgLwpInq3rwSoHcRwPkJ8+59NOd0osYaC MIlOLL2TUah8IBAv/W5prROIKjNCP9rboYdLgw0FHfZ1MeA7WPtMtKIEMPVU6io+ ploVb44TDGMnvp1UZsA/h58qmT1aycmdA88WY51BcGSx7f+QiqboXEqDT6vtlRIg HvYly/ksodCOrUfEk7k3GGpd0O1qQWVmIEyKG0GiY/nJyP0gQ7579fFbFk++5Zug SAhi+KHC/bNuuSSg1tPDddDz/DhV1fBrgBkRyPj2Bzx1GxL1DP5vTRFxqERTNtvk OU8PBzK+wUnQjAoE25hAv+iceVAMoSJWZ/y7IHnoAjk7u9AThxrYhKG/jY5pN2uO akIx5NhwRJlmpyWFCPhU1xVktpiHJyiSgD05F8TDUKjI4yZQI7/aypi1D9zchOzv 5u+au2qwOmwpL7wszWBwSA79d4lrw6vhjgX5atQzIsNkO8YHt9uDGsGpsXIYXF1n auXi4uHR1cUrKUhQ8Usj =il1p -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
